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1 Scope 

The present document specifies the Test Suite Structure and Test Purposes (TSS&TP) for NGN/IMS interconnection 
tests at the Ic Interface to verify the overall compatibility of SIP, ISDN and non-ISDN (PSTN) over the national or 
international NGN networks under consideration of the use of End Devices in the relevant networks (recommended by 
the network operator). The TSS&TP specification covers the procedures described in TS 124 229 [2] and 
TS 129 165 [1] respectively. 

The specified Test Purposes are the basis for bilateral tests between national or international network operators. Even if 
tests between network operators is agreed, exactly the test purposes defined in the current document are be performed. 
Modification of the requirements as described in TS 124 229 [2] and TS 129 165 [1] based on national requirements 
needs additional Test Purposes not described in the present document. This additional test may be defined and agreed 
between the test staff of the network operators. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http : //docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 



2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 129 165: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Inter-IMS Network to Network Interface (NNI) 
(3GPP TS 29.165 Release 10)". 

[2] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229 
Release 10)". 

[3] IETF RFC 4566 (2006): "SDP: Session Description Protocol". 

[4] IETF RFC 3261 (2002): "SIP: Session Initiation Protocol". 

[5] IETF RFC 3264 (2002): "An Offer/Answer Model with the Session Description Protocol (SDP)". 

[6] IETF RFC 3312 (2002): "Integration of Resource Management and Session Initiation 

Protocol (SIP)". 

[7] ETSI TS 124 607: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Originating Identification Presentation (OIP) and 
Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) 
subsystem; Protocol specification (3GPP TS 24.607 Release 10)". 

[8] ETSI TS 124 608: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) using IP Multimedia (IM) Core Network (CN) 
subsystem; Protocol specification (3GPP TS 24.608 Release 10)". 
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[9] ETSI TS 124 604: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication Diversion (CDIV) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.604 
version 10.3.0 Release 10)". 

[10] ETSI TS 124 605: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Conference (CONF) using IP Multimedia (IM) Core 
Network (CN) subsystem; Protocol specification (3GPP TS 24.605 Release 10)". 

[11] ETSI TS 124 629: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Explicit Communication Transfer (ECT) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.629 
Release 10)". 

[12] ETSI TS 124 611: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Anonymous Communication Rejection (ACR) and 
Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification (3GPP TS 24.61 1 Release 10)". 

[13] ETSI TS 124 654: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Closed User Group (CUG) using IP Multimedia (IM) 
Core Network (CN) subsystem, Protocol Specification (3GPP TS 24.654 Release 10)". 

[14] ETSI TS 124 642: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Completion of Communications to Busy Subscriber 
(CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) 
Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.642 Release 10)". 

[15] ETSI TS 124 615: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication Waiting (CW) using IP Multimedia 
(IM) Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.615 Release 10)". 

[16] ETSI TS 124 606: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Message Waiting Indication (MWI) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.606 
Release 10)". 

[17] ETSI TS 124 610: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Communication HOLD (HOLD) using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.610 
Release 10)". 

[18] ETSI TS 124 616: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Malicious Communication Identification (MCID) 
using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.616 
Release 10)". 

[19] ETSI TS 129 658: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; TISPAN; SIP Transfer of IP Multimedia Service 
Tariff Information; Protocol specification (3GPP TS 29.658 Release 10)". 

[20] ETSI TS 124 628: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Common Basic Communication procedures using IP 
Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.628 
Release 10)". 

[21] IETF RFC 5009 (September 2007): "Private header (P-Header) extension to the Session Initiation 

Protocol (SIP) for authorization of Early Media". 

[22] ITU-T Recommendation V.152 (November 2004): "Procedures for supporting Voice-Band Data 

over IP Networks". 

[23] ITU-T Recommendation T.38 (September 2010, prepublished): "Procedures for real-time Group 3 

facsimile communication over IP networks". 
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[24] ITU-T Recommendation Q. 1912.5: "SERIES Q: SWITCHING AND SIGNALLING 

Specifications of signalling related to Bearer Independent Call Control (BICC) Interworking 
between Session Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN 
User Part". 

[25] ETSI TS 183 036: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i. 1] ETSI EN 300 403-1 : "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling 

System No. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; 
Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[i.2] ISO/IEC 9646 (1994): "Information technology — Open Systems Interconnection — Conformance 

testing methodology and framework" . 

[i.3] ETSI TR 102 775 (Vl.5.1): "Speech and multimedia Transmission Quality (STQ); Guidance on 

objectives for Quality related Parameters at VoIP Segment-Connection Points; A support to NGN 
transmission planners". 

[i.4] ITU-T Recommendation Q. 1902.2 (07/2001): "Bearer Independent Call Control protocol 

(Capability Set 2) and Signalling System No. 7 ISDN User Part: General functions of messages and 
parameters". 



3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

For BICC or ISUP specific terminology, reference shall be made to ITU-T Recommendation Q. 1902.2 [i.4]. For SIP 
and SDP specific terminology, reference shall be made to RFC 3261 [4] and RFC 4566 [3] respectively. Definitions for 
additional terminology used in this interworking Recommendation are as follows: 

Adjacent SIP Node (ASN): SIP node (e.g. SIP Proxy or Back-to-Back User Agent or the SIP side of an IWU) that has 
established a direct trust relation (association) with Incoming or Outgoing IWU entities 

NOTE: The SIP Proxy and Back-to-Back User Agent are defined in accordance with RFC 3261 [4]. 

Basic Call Control (BCC): signalling protocol associated with the DSS1 - ISDN Basic Call control procedures of 
ITU-T recommendation Q.931 [15] (EN 300 403-1 [i.l]) 

Incoming Interworking Unit (I-IWU): physical entity, (which can be combined with a BICC ISN or ISUPexchange) 
that terminates incoming calls using SIP and originates outgoing calls using the BICC or ISUP protocols 

incoming or outgoing: direction of a call (not signalling information) with respect to a reference point 

incoming SIP or BICC/ISUP (network): network, from which the incoming calls are received, that uses the SIP or 
BICC/ISUP protocol (without the term "network", it simply refers to the protocol) 

inopportune: specifies a test purpose covering a signalling procedure where an inopportune message (type of message 
not expected in the IUT current state) is sent to the IUT 

Outgoing Interworking Unit (O-IWU): physical entity, (which can be combined with a BICC ISN or ISUP exchange) 
that terminates incoming calls using BICC or ISUP protocols and originates outgoing calls using the SIP 
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outgoing SIP or BICC/ISUP (network): network, to which the outgoing calls are sent, that uses the SIP or 
BICC/ISDN protocol 

NOTE: Without the term "network", it simply refers to the protocol. 

SIP precondition: indicates the support of the SIP "precondition procedure" 

NOTE: as defined in RFC 33 12 [6] . 

syntactically invalid: specifies a test purpose covering a signalling procedure where a valid (expected in the current 
status of the IUT) but not correctly encoded (unknown or incorrect parameter values) message is sent to the IUT, which 
shall react correctly and eventually reject the message 

test purpose: non-formal test description, mainly using text 

NOTE: TSIs test description can be used as the basis for a formal test specification (e.g. Abstract Test Suite in 
TTCN). See ISO/IEC 9646 [i.2]. 

valid: specifies a test purpose covering a signalling procedure where all the messages sent to or received from the IUT 
are valid (expected in the current status of the IUT) and correctly encoded 

3.1 .1 Conventions for representation of SIP/SDP information 

1) All letters of SIP method names are capitalized. 
EXAMPLE 1 : INVITE, INFO. 

2) SIP header fields are identified by the unabbreviated header field name as defined in the relevant RFC, 
including capitalization and enclosed hyphens but excluding the following colon. 

EXAMPLE 2: To, From, Call-ID. 

3) Where it is necessary to refer with finer granularity to components of a SIP message, the component concerned 
is identified by the ABNF rule name used to designate it in the defining RFC (generally 25/RFC 3261 [4]), in 
plain text without surrounding angle brackets. 

EXAMPLE 3: Request-URI, the user info portion of a sip: URL 

4) URI types are represented by the lower-case type identifier followed by a colon and the abbreviation "URI" 
EXAMPLE 4: sip: URI, tel: URI. 

5) SIP provisional responses and final responses other than 2XX are represented by the status code followed by 
the normal reason phrase for that status code, with initial letters capitalized. 

EXAMPLE 5 : 1 00 Trying, 484 Address Incomplete. 

6) Because of potential ambiguity within a call flow about which request a 200 OK final response answers, 200 
OK is always followed by the method name of the request. 

EXAMPLE 6: 200 OK INVITE, 200 OK PRACK. 

7) A particular line of an SDP session description is identified by the two initial characters of the line — that is, 
the line type character followed by "=" 

EXAMPLE 7: m=line, a=line. 

8) Where it is necessary to refer with finer granularity to components of a session description, the component 
concerned is identified by its rule name in the ABNF description of the SDP line concerned, delimited with 
angle brackets. 

EXAMPLE 8: the <media> and <fmt> components of the m= line. 
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3.2 Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ACR 


AnnnvmniK f^nmmnnipatinn Ppipptinn 

.fi.llvJll y lllvJ Uo V_^vJllllllUlll^dLlvJll AVCJ LlvJll 


CR 


f^nmmiimr'Jitinn R^TTincr 

V^UllllllUlll^dllvJll JJdlllllii 


CFB 


f^nmmiini potion T-ioTAx/JirrlincT Riiqv 

v^UllllllUlll^dllvJll 1 Ul W dl U-lllci -ULloV 


CCBS 


Comnlption of Communications to Rusv Subscriber 


CCNR 


Comnlption of Communications bv No RpdIv 


CD 


f^ommnnication T")pflpction 


CDIV 


Communication Diversion 


CDP 


f^harcrincr T^pfprminatincr Point 

Vw^lldl cilll lyCLCl lllllldLlllci JT Ullll 


CDR 


r^ommiinipation T")ata PpporH 

Vw^vJllllllUlll^dLlvJll -LVdLd AVt^vJlU. 


CFNL 


r^ommnnipation T-^nrwarHincr lSTot T ocrcrprl in 

Vw^vJllllllUlll^dLlvJll 1 Ul Wdld-lllci INvJl -L/vJcLcidJ. Ill 


CFNR 


Pnmmnnipatinn T^nrwarHincr lSTo Ppnlv 

Vw^vJllllllUlll^dLlvJll 1 vJl W dl d-lllci INvJ AvtPJJlV 


CFU 


Pnmmnnipatinn T^nrwarHincr T TnponHitional 

Vw^vJllllllUlll^dLlvJll 1 \JL W dl d-lllci l_J ll^vJlldlLlvJlldl 


CONF 


Confprpncp 

V vylllV^l 1 1 


CUG 


Clospd ITspr Gronn 


CW 


f^ommnnication W/aitincr 

V v7111111Lilll^ClLlV/ll VV CllLlllci 


ECT 


T^Yr>1iPit Pnmmiitiipatinn TranQfpr 

_L/A.U11U11 v^UllllllUlll^dllvJll XldllolCl 


GW 


f-ratpW^a v 
vjcut tv ay 


HOLD 


Communication Hold 


ISDN 


Tntpcrratprl ^prvippQ T^icntal lSTptworV 

-LllLC^cil dLdJ. OdVl^C^o J-VlcilLdl 1 > L L W U 1 IV 


IUT 


Tmr>1pmpntation TTnHpr TpQt 

J-llllJldllt^llLdLlvJll LJlldd ICol 


MCID 


Malicious Communication Identification 

_LV J_CIAJ-\^J-V/ U-i3 KsVJ 111111 LI 111 v/ CI LI V_7 11 XV^V/11 Ul 1 1 v/CLLl V_/ll 


MWI 


Message Waiting Indication 


DTP 


wllgllldllllg lUeilLlllCdLlOIl r leseiiLdLioii 


OIR 


Originating Identification presentation Restriction 


PASP 


Public Answering Safety Point 


PICS 


Protocol Implementation Conformance Statement 


PSTN 


Public Switched Telephone Network 


QoS 


Quality of service 


SIP 


Session Initiation Protocol 


TIP 


Terminating Identification Presentation 


TIR 


Terminating Identification Restriction 


TP 


Test Purpose 


TSS 


Test Suite Structure 
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Test Suite Structure (TSS) 



BCALL 


successful 


SS 


_bcall_xxx 




Codec_Negotiation 


SS 


codec xxx 




Resource_Reservation 


SS 


_resource_xxx 




unsuccessful 


SS 


unsucc xxx 



SIP-SIP 



Service 



OIP 



OIR 



TIP 



TIR 



HOLD 



CFU 



CFB 



CFNR 



CFNL 



CD 



CONF 



ACR-CB 



CUG 



CW 



ECT 



MCID 



MWI 



CC 



SS_oip_xxx 



SS oir xxx 



SS_tip_xxx 



SS tir xxx 



SS hold xxx 



SS cfu xxx 



SS cfb xxx 



SS cfnr xxx 



SS cfnl xxx 



SS cd xxx 



SS conf xxx 



SS acr-cb xxx 



SS_cug_xxx 



SS cw xxx 



SS ect xxx 



SS mcid xxx 



SS mwi xxx 



SS cc xxx 



SIP-I 


uus 


SS_uus_xxx 




SUB 


SS_sub_xxx 




TP 


SS_tp_xxx 



NubP 



SS NP xxx 



ACCOUNTING 



SS acc xxx 



CS 



SS csel xxx 



EmC 



SS ecall xxx 



SIP_charging 



SS_sipc_xxx 



SIP-SIP/QoS 



SS_qos_xxx 



5 Declarations 

5.1 Numbering Scheme 

FFS 

5.2 Reference configuration 

This reference configuration depicted in figure 5.2-1 shall be used to perform an interconnection test between two 
network operators. Here is depicted the reference point to observe the message flow at the Tc' interface between the two 
networks (in the Testpurposes mentioned Interconnection Interface') one for a single operator and the possible set of 
end devices used to perform the Test Purposes. 
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1 1 


Network A 


DSS1 








IBCF A 


POT9 

r\J 1 o 


GSM 


\/nl TF 

VUL 1 C 






PSTN 










Network B 


SIP 


■ IBCF B 




Uool 


r\J 1 O 


OOIVI 






VoLTE 




P^TN 

1 O 1 IN 







Figure 5.2-1 : Reference configuration for the interconnection test 



5.3 Selection of End Devices 

With the specified Test Purposes in the present document, the compatibility between the interconnected networks and 
the used end devices in the relevant networks shall be assured. Each Test Purpose shall be performed by using a 
physical end device to assure the end-to-end compatibility between the two interconnected networks. This is strictly 
recommended due to the fact that the impact from a end device to another end device is important and will marginal 
compensated by the network. 

Which Test Purposes are possible to perform depends on the types of end devices is used in the relevant network. The 
table 5.3-1 gives an overview of the end devices used in the relevant networks. The test staff of the network operator 
decides which type of end device is applicable for the test phase. 

The green highlighted element in the table represents the mandatory type of end devices used in the test. 
The yellow highlighted elements in the table represents the optional type of end devices used in the test. 



Table 5.3-1 : Used end devices in the relevant network 



Type of 
End devices 


Network B 


Network A 


SIP 


POTS 


ISDN 


GSM 


VoLTE 


PSTN 




SIP 
















POTS 
















ISDN 
















GSM 
















VoLTE 
















PSTN 
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6 Selection Expressions 

Table 6-1 is used to select the optional Test Purposes for the compatibly test between network operator A and network 
operator B. The decision whether a Selection Expression id fulfilled is basically agreed regarding the role of the 
network in the test. 

• Network operator 1 is in the role of Network A, Network operator 2 is in the role of Network B. 
In case of Repeat this test in reverse direction, mentioned in the Comment line in the Test Purpose. 

• Network operator 2 is in the role of Network A, Network operator 1 is in the role of Network B. 

In each Test Purpose is determined in the field SELECTION EXPRESSION whether the selection expression applies 
and the Test Purpose shall be performed. It has to be decided in which role the Test purpose is applicable (Support 
Network A, Support Network B). 

Before start of test, the table shall be filled out (yes/no) due to the operators gives an answer to the questions in 
table 6-1. This table can be used as a PICS form as used in a conformance test. 



Table 6-1 : Selection expression applicable in the Test Purposes 



SELECTION EXPRESSION: 


Support 


Support 








Network capabilities 


SE 1 : The originating network (Network A) sends the P-Charging-Vector 
header 






SE 2: The originating network (Network A) sends a subset of parameters in 
the P-Charging-Vector header 






SE 3 


The P-Early-Media header is supported 






SE 4 


Overlap procedure using multiple INVITE method is supported 






SE 5 


Overlap sending using in-dialog method is supported 






SE 6 


Network A supports the PSTN XML schema? 






SE 7 


The resource reservation procedure is supported? 






SE 8 


The Number Portability is supported? 






SE 9 


The network is untrusted? 






SE 10: Originating network does not have a number portability data base, the 
number portability look up is done in the interconnected network? 






SE 1 1 : The network supports the REFER method? 






SE 12: The Network supports the 3 party call control procedure (REFER 
interworking)? 






SE 13: The Number Portability is supported? 






SE 14: Carrier Selection is performed? 






SE 15: The Network is a Long distance carrier (Verbindungsnetzbetreiber - 
VNB) 






SE 16: SIP Support of Charging is supported? 






SE 17: The interworking ISUP - SIP I is performed in the network 






Supplementary services 


SE 18: The network supports the Originating Identification Presentation 
(OIP)? 






SE 19: The network supports the "Special arrangement" procedure for the 
originating user? 






SE 20: The network supports the Originating Identification Restriction (OIR)? 






SE 21 : The Network supports the Terminating Identification Presentation 
(TIP)? 






SE 22: The network supports the "Special arrangement" procedure for the 
terminating user? 






SE 23: The Network supports the Terminating Identification Restriction (TIR)? 






SE 24: The Network supports the session HOLD procedure? 






SE 25: The network supports Communication Forwarding Unconditional 
(CFU)? 






SE 26: The network supports Communication Forwarding Busy (CFB)? 






SE 27: The network supports Communication Forwarding No Reply (CFNR)? 






SE 28: The Network supports Communication Forwarding Not Logged in 
(CFNL) 
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Qimnnrt 


Qnnnnrt 




Network A 


Network B 


SE 29 


The Network supports Communication Deflection? 






SE 30 


The Network supports the CDIV Notification procedure? 






SE 31 


The Network supports conference (CONF) 






SE 32 


The Network supports the Communication Barring procedure (CB) - 
(Black list for incoming calls)? 






SE 33: The Network supports the Anonymous Communication Rejection 
(ACR)? 






SE 34 


The Network supports the Closed User Group (CUG)? 






SE 35 


The Network supports the Communication Waiting (CW) service? 






SE 36 


The Network supports the Tas-cw timer? 






SE 37 


The Network supports Explicit Communication Transfer (ECT)? 






SE 38 


The network supports Malicious Communication Identification (MCID) 






SE 39 


The Network supports Message Waiting Indication (MWI)? 






SE 40 


The Network supports Completion of Communications to Busy 
Subscriber (CCBS)? 






SE 41 : The Network supports Completion of Communications by No Reply 
(CCNR) 






Terminal capabilities 


SE 42: The End device (in Network B) establishes an Early dialogue by 

sending a 183 AND The Network B allows the bearer transmission in 
the early dialogue 






SE 43 


The End device supports Fax transmission via G.71 1 codec 






SE 44 


The End device supports Fax transmission via V.152 codec 






SE 45 


The End device supports Fax transmission via m-line T.38 codec 






SE 46 


A SIP end device is used supporting a ISDN user equipment and the 
PSTN XML Schema is used 






SE 47: End device is located in the PSTN or PLMN 






SE 48: The terminating UE supports the from-change tag procedure and 
sends a second user identity in an UPDATE request after the 
dialogue is confirmed 






SE 49 


The end device performs ECT using the 'Blind/assured transfer' 






SE 50 


The end device performs ECT using the 'Consultative transfer' 






SE 51 


The end device supports the Resource reservation procedure 






PSTN/PLMN Supplementary services 


SE 52 


CLIP/CLIR is supported in the PSTN/PLMN part of the network 






SE 53 


COLP/COLR is supported in the PSTN/PLMN part of the network 






SE 54 


HOLD is supported in the PSTN/PLMN part of the network 






SE 55 


CDIV is supported in the PSTN/PLMN part of the network 






SE 56 


CONF/3PTY is supported in the PSTN/PLMN part of the network 






SE 57 


ACR is supported in the PSTN/PLMN part of the network 






SE 58 


CUG is supported in the PSTN/PLMN part of the network 






SE 59 


CW is supported in the PSTN/PLMN part of the network 






SE 60 


ECT is supported in the PSTN/PLMN part of the network 






SE 61 


MCID is supported in the PSTN/PLMN part of the network 






SE 62 


SUB is supported in the PSTN/PLMN part of the network 






SE 63 


UUS is supported in the PSTN/PLMN part of the network 






SE 64 


TP is supported in the PSTN/PLMN part of the network 







7 Test purposes 

The application usage procedures in the ATS shall be compliant to TS 129 165 [1], TS 124 229 [2] and RFC 3261 [4]. 
The validation of the registration procedure is out of scope of the present document. 

The preconditions mechanism shall be supported by the UE in case of supporting IMS. 
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7.1 Testing of SIP protocol requirements 



7.1 .1 Test purposes for Basic call, Successful 



Test case number 


SS_bcall_001 


Test case group 


BCALL/successful 


Reference 


[4] 


SELECTION EXPRESSION 




Test purpose 


Basic call normal call clearing from the called user. 

Ensure that call establishment is performed correctly. In the active call state 
ensure the property of speech. The call is released from the called user. 


Configuration 




SIP Parameter 




Message flow 


SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
180 Ringing 
200 OK INVITE 

ACK 
Communication 

200 OK BYE 


Comments 


Establish a communication from network A to Network B 
Check: Ensure the property of speech. 

Check: Are the media streams terminated after the 200 OK BYE was sent? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 




Test case number 


SS_bcall_002 


Test case group 


BCALL/successful 


Reference 


[4] 


SELECTION EXPRESSION 




Test purpose 


Basic call normal call clearing from the calling user. 

Ensure that call establishment is performed correctly. In the active call state 
ensure the property of speech. The call is released from the calling user. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
180 Ringing 
200 OK INVITE 

ACK 
Communication 

200 OK BYE 


Comments 


Establish a communication from network A to Network B 
Check: Ensure the property of speech. 

Check: Are the media streams terminated after the 200 OK BYE was sent? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 003 


Test case group 


BCALL/successful 


Reference 


8/m 


SELECTION EXPRESSION 




Test purpose 


Request line in the INVITE. 

Ensure that the Request line in the INVITE contains in the userpart the 
telephone number of the destination user equipment formatted as a 'tel' URI in 
the global number format and the host portion is set to the host name of the 
interconnected network. The user URI parameter is present set to 'phone'. 


Configuration 




SIP Parameter 


INVITE 

Request line Address of user B @ network B;user=phone 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The userpart is in the format of a tel URI in global number format. 

Check: The hostportion is set to the host name of the interconnected network. 

Check: The user parameter is set to phone. 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 




Test case number 


SS_bcall_004 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


Testspec Reference 




SELECTION EXPRESSION 


SE 1 


Test purpose 


P-Charging-Vector header in the INVITE. 

Ensure that the P-Charging-Vector header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
'icid-value' and the 'orig-ioi' parameter is present. 


Configuration 




SIP Parameter 


INVITE 

P-Charging-Vector: icid-value; orig-ioi 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: The P-Charging-Vector header contains the icid-value parameter. 
Check: The P-Charging-Vector header contains the orig-ioi parameter. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 005 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


Testspec Reference 




SELECTION EXPRESSION 


SE 2 


Test purpose 


P-Charging-Vector header in the INVITE. 

Ensure that the P-Charging-Vector header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
'icid-value' or the 'orig-ioi' parameter is present. 


Configuration 




SIP Parameter 


INVITE 

P-Charging-Vector: icid-value; orig-ioi 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: The P-Charging-Vector header contains the icid-value parameter 
(optional). 

Check: The P-Charging-Vector header contains the orig-ioi parameter 

(optional). 
Repeat this test in reverse direction. 




Test case number 


SS bcall 006 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 


Test purpose 


P-Early-Media header support indication in the initial INVITE request. 

Ensure that the support of the P-Early.Media header is indicated in the initial 
INVITE request. A P-Early-Media header is present set to 'supported'. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is a P-Early-Media header is present in the INVITE request? 

Repeat this test in reverse direction. 



ETSI 



18 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS_bcall_007 


Test case group 


BCALL/successful 


Reference 


o /ro h l 

8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE3 AND SE 42 


Test purpose 


P-Early-Media header supported early dialogue with 183. 

Ensure that an early dialogue is established by sending a 183 Session Progress 
from Network B and the P-Early-Media header is present authorizes early media. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

183 

P-Early-Media: [any value authorizes early media] 
SDP 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
183 Session Progress 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is a 1 83 sent from Network B to establish an early dialogue? 
Check: A bearer transmission is possible in backward directions. 
Repeat this test in reverse direction. 




Test case number 


SS_bcall_008 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE 3 


Test purpose 


P-Early-Media header supported early dialogue with 180. 

Ensure that an early dialogue is established by sending a 180 Ringing from 
Network B and the P-Early-Media header is present authorizes early media. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

180 

P-Early-Media: [any value authorizes early media] 
SDP 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is a 1 83 sent from Network B to establish an early dialogue? 
Check: A bearer transmission is possible in backward directions. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 009 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE 3 AND SE 25 AND SE 30 


Test purpose 


P-Early-Media header supported early dialogue with 181. 

Ensure that an early dialogue is established by sending a 181 Call Is Being 
Forwarded from Network B and the P-Early-Media header is present authorizes 
early media. The Call is forwarded in network B. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 


SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

181 

P-Early-Media: [any valu authorizes early media] 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 

180 Call Is Being Forwarded 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is a 181 sent from Network B to establish an early dialogue? 

Repeat this test in reverse direction. 




Test case number 


SS_bcall_010 


Test case group 


BCALL/successful 


Reference 


8/[21] 


SELECTION EXPRESSION 


[Network A] SE 3 AND [Network B] SE 3 AND SE 35 


Test purpose 


P-Early-Media header supported early dialogue with 182. 

Ensure that an early dialogue is established by sending a 182 Queued from 
Network B and the P-Early-Media header is present authorizes early media. The 
Call is a waiting call in network B. 


Configuration 




SIP Parameter 


INVITE 

P-Early-Media: supported 
SDP 

182 

P-Early-Media: [any value authorizes early media] 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 

180 Call Is Being Forwarded 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is a 181 sent from Network B to establish an early dialogue? 

Repeat this test in reverse direction. 
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Test case number 


SS_bcall_011 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Record-route header in the INVITE. 

Ensure that the Via header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
topmost header is set to the IBCF of network A. 


Configuration 




SIP Parameter 


INVITE 

Record-Route: <Address of IBCF in network A> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The topmost Record-Route header or entry contains the address of 

the IBCF of network A. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 




Test case number 


SS_bcall_012 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Via header in the INVITE. 

Ensure that the Via header is present in the INVITE establishes a 
communication between a user of network A and a user of network B and the 
topmost header is set to the IBCF of network A and contains a branch 
parameter. 


Configuration 




SIP Parameter 


INVITE 

Via: <Address of IBCF in network A>; branch=[any value] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The topmost Via header contains the Address of IBCF in network A 

and a branch parameter. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS_bcall_013 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Record-Route header in the 180 Ringing. 

Ensure that the Record-Route header is present in the 180 Ringing provisional 
response as the first response from network B upon a connection establish setup 
from network A. 


Configuration 




SIP Parameter 


180: 

Record-Route 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The Record-Route header is present is present in the 180 Ringing. 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 




Test case number 


SS_bcall_014 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Route header in the BYE of the originating user. 

Ensure that the Route header is present in the BYE request sent from the 
originating user equipment in network A and the topmost Route header or entry 
is set to the IBCF of network B. 


Configuration 




SIP Parameter 


BYE: 

Route: <Address of IBCF in network B>;lr, .... 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
BYE 
200 OK BYE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The Route header is present is present in the BYE and the topmost 

header or entry is set to the address of the IBCF of network B. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS_bcall_015 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Route header in the BYE of the terminating user. 

Ensure that the Route header is present in the BYE request sent from the 
terminating user equipment in network B and the topmost Route header or entry 
is set to the IBCF of network A. 


Configuration 




SIP Parameter 


BYE: 

Route: <Address of IBCF in network A>;lr, .... 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
BYE 
200 OK BYE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: The Route header is present is present in the BYE and the topmost 

header or entry is set to the address of the IBCF of network A. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 




Test case number 


SS_bcall_016 


Test case group 


BCALL/successful 


Reference 


5.10/[2] 


SELECTION EXPRESSION 




Test purpose 


Route header in the ACK. 

Ensure that the Route header is present in ACK from network A upon a 
connection establishment from network A is completed and the topmost Route 
header or entry is set to the IBCF of network B. 


Configuration 




SIP Parameter 


ACK: 

Route: <Address of IBCF in network B>;lr, .... 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Route header is present is present in the ACK and the topmost header 

or entry is set to the address of the IBCF of network B. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 017 


Test case group 


BCALL/successful 


Reference 


[4] and [5] 


SELECTION EXPRESSION 




Test purpose 


Handling of SDP parameters in the INVITE. 

Ensure that call establishment and the correct handling of the SDP parameters 
of the INVITE message defined as: TYPE_SDP is performed correctly. Ensure 
that in the active call state the voice/data transfer on the media channels is 
performed correctly (e.g. testing QoS parameters). In case when the parameter 
in the SDP rtpmap:<dynamic-PT> is used the codecs in table 7.1.1-1 applies. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: application/sdp 

m=audio <Port number> RTP/AVP TYPE_SDP= PIXIT (table 7.1.1-1) 
or 

m= Image <Port number> Udptl orTcptl TYPE SDP= PIXIT (table 7.1.1-1) 
a=TYPE SDP= PIXIT (table 1) 
b=TYPE_SDP= PIXIT (table 1) 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is the preferred codec set to TYPE_SDP? 
Check: If present: is the a line set to TYPE_SDP? 
Check: If present: is the b line set to TYPE_SDP? 

Check: Is the codec list consistent with the attribute(s) (bandwidth) regarding 

the media description? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 




Test case number 


SS_bcall_018 


Test case group 


BCALL/successful 


Reference 


[4] and [5] 


SELECTION EXPRESSION 




Test purpose 


The SDP answer is sent in the 200 OK. 

Ensure that the call establishment performed correctly. 

The initial INVITE contains a SDP with the offer 1 according table 7.1 .1 -1 . 

Ensure that answer related to the SDP offer is contained in the 200 OK INVITE 

message. 

Ensure that in the confirmed state the voice transfer on the media and B- 
channels is performed correctly. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

Apply post test routine 


Interconnection Interface SIP (Network B) 

INVITE (SDP1) 
180 Ringing 
200 OK INVITE (SDP2) 
ACK 


Comments 


Establish a communication from network A to Network B 
Check: Is the SDP answer contained in the 200 OK INVITE. 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS bcall 018 


Test case group 


BCALL/successful 


Reference 


[4] and [5] 


bbLbO I IUN bArnboolUN 




Test purpose 


First response 200 OK INVITE. 

Ensure that call establishment and the correctly if the called user answers with a 
200 OK message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
200 OK INVITE 

ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is it possible to confirm a session without early dialogue? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 



Table 7.1.1-1 



TYPE_SDP m = line 


b= line 


a= line 


VA 


<media> 


<transport> 


<fmt-list> 


<modifier>:<bandwidth- 
value> 
(see note) 


rtpmap:<dynamic-PT> <encoding 
name>/<clock rate>[/encoding 
parameters> 


VA 01 


Audio 


RTP/AVP 





N/A or up to 64 kbit/s 


N/A or rtpmap PCMU/8000 


VA 02 


Audio 


RTP/AVP 


Dynamic PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> PCMU/8000 


VA 03 


Audio 


RTP/AVP 


8 


N/A or up to 64 kbit/s 


N/A or rtpmap 8 PCMA/8000 


VA 04 


Audio 


RTP/AVP 


Dynamic PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> PCMA/8000 


VA 05 


audio 


RTP/AVP 


Dynamic PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> CLEARMODE 


NOTE: <bandwidth value> for <modifier> of AS is evaluated to be B kbit/s. 



Test case number 


SS bcall 020 


Test case group 


BCALL/successful 


Reference 


[4] and [5] 


SELECTION EXPRESSION 


[Network A] SE 43 AND [Network B] SE 43 


Test purpose 


Fax transmission using the G.711 codec. 

Ensure that a Fax transmission is possible from Network A to Network B and the 
relevant codec is the G.71 1 codec. Ensure in the active call state the property of 
Fax transmission. 


Configuration 




SIP Parameter 


INVITE: SDP 

m=audio <Port> RTP/AVP 8/0 
180/200 OK INVITE: SDP 

m=audio <Port> RTP/AVP 8 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (SDP1) 
180 Ringing 
200 OK INVITE (SDP2) 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is the SDP answer contained in the 200 OK INVITE. 
Check: is Fax transmission is successful? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 021 


Test case group 


BCALL/successful 


Reference 


[5] and [22] 


api rATIAkl 1"" \e |-» n [— /-\ O 1 /~\ Iv 1 

SELECTION EXPRESSION 


r K 1 ■ 1 A 1 1 — A A A K 1 l~\ rk 1 J. 1 A 1 1 — A A 

[Network A] SE 44 AND [Network A] SE 44 


Test purpose 


Fax transmission using the V.152 codec. 

Ensure that a Fax transmission is possible from Network A to Network B and the 
relevant codec is the V.152 codec. Ensure in the active call state the property of 
Fax transmission. 


Configuration 




SIP Parameter 


INVITE: SDP 

m=audio <Port> RTP/AVP 8 <dynamic-PT> 
a=rtpmap <dynamic-PT> PCMA/8000 
a=gpmd; vbd=yes 

180/200 OK INVITE: SDP 

m=audio <Port> RTP/AVP <dynamic-PT> 
a=rtpmap <dynamic-PT> PCMA/8000 
a=gpmd; vbd=yes 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE (SDP1) 
180 Ringing 
200 OK INVITE (SDP2) 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Contains the SDP offer in the initial INVITE a voice band data codec. 

Check: contains the SDP answer in the 1 80 or 200 OK INVITE a voice band 

data codec. 
Check: Is Fax transmission is successful? 
Repeat this test in reverse direction. 




Test case number 


SS_bcall_022 


Test case group 


BCALL/successful 


Reference 


[5] and [23] 


SELECTION EXPRESSION 


[Network A] SE 45 AND [Network B] SE 45 


Test purpose 


Fax transmission using the T.38 in an audio m-line codec. 

Ensure that a Fax transmission is possible from Network A to Network B and the 
relevant codec is the T.38 in an 'audio' m-line codec. Ensure in the active call 
state the property of Fax transmission. 


Configuration 




SIP Parameter 


INVITE: SDP 

m=image <Port> udptl t38 

180/200 OK INVITE: SDP 

m=image <Port> udptl t38 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE (SDP1) 
180 Ringing 
200 OK INVITE (SDP2) 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Contains the SDP offer in the initial INVITE a T.38 codec in an 'audio' 
line. 

Check: Contains the SDP answer in the 1 80 or 200 OK INVITE a T.38 codec 

in an 'audio' line. 
Check: Is Fax transmission is successful? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 


023 




Test case group 


BCALL/successful 


Reference 


4.9, N/[2] 


SELECTION EXPRESSION 


[Network A] SE 47 AND [Network A] SE 4 AND [Network B] SE 4 


Test purpose 


Overlap sending, the Multiple INVITE method is used. 

Ensure that call establishment using overlap sending is performed correctly. 
Ensure that in the confirmed state the voice transfer on the media and B-channels 
is performed correctly. 


Configuration 




SIP Parameter 




Messaae flow 

SIP (Network A) 




Interconnection Interface 

INVITE(CSq 1) 


SIP (Network B) 






INVITE(CSq 2) 
484 Address lncomplete(CSq 1) 
ACK 








INVITE(CSq 3) 
484 Address lncomplete(CSq 2) 
ACK 








INVITE(CSq 4) 
484 Address lncomplete(CSq 3) 
ACK 

180 Ringing(CSq 4) 
Apply post test routine 




Comments 


Establish a communication from ISDN to SIP using the overlap operation in ISDN 
Check: All INVITE requests contains the same Call ID and From header 
values. 

SIP answers with 180 Ringing. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 024 


Test case group 


BCALL/successful 


Reference 


4.9, N/[2] 


SELECTION EXPRESSION 


[Network A] SE 47 AND [Network A] SE 4 AND [Network B] SE 5 


Test purpose 


Overlap sending, the in-Dialogue method is used 

Ensure that call establishment using overlap sending is performed correctly. 
Ensure that in the confirmed state the voice transfer on the media and B-channels 
is performed correctly. 


Configuration 




SIP Parameter 


INVITE 2: 

Supported: 1 0Orel 

183: Require: 1 0Orel 

INFO: 

Content-Type: application/x-session-info 
SubsequentDigit: <additional digits> 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(CSq 1) 1 * 
484 Address lncomplete(CSq 1 ) 
ACK 

INVITE(CSq 2) 2 

1 83 Session Progress(CSq 2) 

PRACK 

200 OK PRACK 
INFO 

200 OK INFO 
INFO 

200 OK INFO 

180 Ringing(CSq 2) 

Apply post test routine 


Comments 


Establish a communication from ISDN to SIP using the overlap operation in ISDN 

Check: All INVITE requests contains the same Call ID and From header values. 

Check: The 183 session Progress that establishes an early dialogue contains a 
Require header set to 1 0Orel. 

Check: All INFO requests contain the Content-Type header set to 'application/x- 
session-info'. 

Check: All INFO requests contains the 'SubsequentDigit:' MIME body containing 

the additional digits. 
The UE B answers with 180 Ringing response after the INVITE was received. 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 025 


Test case group 


BCALL/successful 


Reference 


5.1 .1 .1 .2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML BearerCapability element in the INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XML MIME body and a BearerCapability 
element as indicated in table 7.1.1-2 is present. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctet3 

CodingStandard>00< ^^^^^ 
lnformationTransferCabability>ITC_value< 
< BCoctet4 

TransferMode>00< 
lnformationTransferRate>1 0000< 
BCoctet5 

Layerl Identification:^ < 
UserlnfoLayerl Protocol>0001 1 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is the BearerCapability element is present? 
Check: Is InformationTransferCabability element is set as indicated in 
table 2.1.1-1? 

Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 



Table 7.1.1-2: PSTN XML BearerCapability 



ITC value 


BC Information transfer capability 


XML InformationTransferCabability 


ITC VA 1 


Speech 




00000' 




ITC VA 2 


3,1 kHz audio 




10000' 




ITC VA 3 


unrestricted digital information 




01000' 
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Test case number 


SS bcall 026 


Test case group 


BCALL/successful 


Reference 


5.1 .1 .1 .2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML HighLayerCapability element in the INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XML MIME body and a HighLayerCapability 
element is present. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

HighLayerCompatibility 
HLOctet3 

CodingStandard>00< 

Interpretation^ 00< 

PresentationMethod>01 < 
HLOctet4 

HighLayerCharacteristics>[any value]< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is the HighLayerCapability element is present? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 027 


Test case group 


BCALL/successful 


Reference 


5.1 .1 .1 .2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML Progresslndicator element in the INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XML MIME body and at least one 
Progresslndicator element is present. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

Progresslndicator 
ProgressOctet3 

CodingStandard>00< 
Location>yyyy< 
ProgressOctet4 

ProgressDescription>00001 1 0< 
Progresslndicator 
ProgressOctet3 

CodingStandard>00< 
Location>0000< 
ProgressOctet4 

ProgressDescription>[any value]< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is a Progresslndicator element present and the ProgressDescription 

element is set to '0000110'? 
Check: Is optional a second Progresslndicator element present and the 

ProgressDescription element is set to any value not #2 and not #8? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 028 


Test case group 


BCALL/successful 


Reference 


5.1.2.2/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


PSTN XML Progresslndicator element in the 180. 

User B is located in network B and an ISDN end device is used. Ensure that the 
180 Ringing response contains a PSTN XML MIME body and at least one 
Progresslndicator element is present. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


180: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

Progresslndicator 
ProgressOctet3 

CodingStandard>00< 
Location>yyyy< 
ProgressOctet4 

ProgressDescription>00001 1 1< 
Progresslndicator 
ProgressOctet3 

CodingStandard>00< 
Location>0000< 
ProgressOctet4 

ProgressDescription>[any value]< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 180 Ringing response? 
Check: Is a Progresslndicator element present and the ProgressDescription 

element is set to '0000110'? 
Check: Is optional a second Progresslndicator element present and the 

ProgressDescription element is set to any value not #2 and not #8? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 029 


Test case group 


BCALL/successful 


Reference 


5.1.2.3/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


PSTN XML Progresslndicator element in the 200. 

User B is located in network B and an ISDN end device is used. Ensure that the 
200 OK INVITE response contains a PSTN XML MIME body and at least one 
Progresslndicator element is present. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


200: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

Progresslndicator 
ProgressOctet3 

CodingStandard>00< 
Location>yyyy< 
ProgressOctet4 

ProgressDescription>00001 1 1< 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 200 OK INVITE 
response? 

Check: Is a Progresslndicator element present and the ProgressDescription 

element is set to '0000110'? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 030 


Test case group 


BCALL/successful 


Reference 


5.1 .1 .1 .2/[25] 


SELECTION EXPRESSION 


[Network A] (SE 46 OR SE 47) AND [Network A] SE 6 


Test purpose 


PSTN XML BearerCapability Fallback connection type element in the 
INVITE. 

User A is located in network A and an ISDN end device is used. Ensure that the 
INVITE request contains a PSTN XML MIME body and one BearerCapability 
element is present the InformationTransferCabability element is set to '00000' 
and one InformationTransferCabability element is set to '10001'. 


Configuration 


User A is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctet3 

CodingStandard>00< 
lnformationTransferCabability>00000< 
BearerCapability 
BCoctet3 

CodingStandard>00< 
lnformationTransferCabability>1 0001 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the INVITE request? 
Check: Is the first BearerCapability InformationTransferCabability element is 

set as indicated to '00000'? 
Check: Is the second BearerCapability InformationTransferCabability element 

is set as indicated to '1 0001 '? 
Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 031 


Test case group 


BCALL/successful 


Reference 


5.1.2.3/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


Fall back does not occur. 

User B is located in network B and an ISDN end device is used. The Fallback 
connection type was requested in the initial INVITE request. Ensure that the 200 
OK INVITE response contains a PSTN XML MIME body and a BearerCapability 
element is present the InformationTransferCabability element set to '10001'. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


200: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctet3 

CodingStandard>00< 
lnformationTransferCabability>1 0001 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 200 OK INVITE 
response? 

Check: Is a BearerCapability element present, the 

InformationTransferCabability element set to '10001'? 

Check: Is the InformationTransferCabability element value consistent with the 
codec list in the SDP? 

Check: Is the InformationTransferCabability element value consistent with the 
bandwidth information in the SDP? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 032 


Test case group 


BCALL/successful 


Reference 


5.1.2.3/[25] 


SELECTION EXPRESSION 


[Network B] (SE 46 OR SE 47) AND [Network B] SE 6 


Test purpose 


Fall back occurs. 

User B is located in network B and an ISDN end device is used. The Fallback 
connection type was requested in the initial INVITE request. Ensure that the 200 
OK INVITE response contains a PSTN XML MIME body and a BearerCapability 
element is present the InformationTransferCabability element set to '00000'. A 
PSTN XML MIME Progresslndicator body is present, the ProgressDescription is 
set to '0000101'. 


Configuration 


User B is an ISDN access either in the PSTN or the SIP - ISDN interworking 
according [10] applies 


SIP Parameter 


200: 

Content-Type: application/vnd.etsi.pstn+xml 
Content-Disposition: signal;handling=optional 

<?xml version="1 .0" encoding="utf-8"?> 
PSTN 

BearerCapability 
BCoctet3 

CodingStandard>00< 
lnformationTransferCabability>00000< 
Progresslndicator 
ProgressOctet4 

ProgressDescription>00001 01 < 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Check: Is a PSTN XML MIME body contained in the 200 OK INVITE 
response? 

Check: Is a BearerCapability element present, the 

InformationTransferCabability element set to '00000'? 

Check: Is a Progresslndicator element is present, the ProgressDescription is 
set to '0000101'? 

Check: Is the InformationTransferCabability element value consistent with the 

codec list in the SDP? 
Check: Is the InformationTransferCabability element value consistent with the 

bandwidth information in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 033 


Test case group 


BCALL/successful 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support, Basic call, IAM present in the INVITE request. 

Ensure that when a call initiated in the PSTN or the PLMN and the ISUP - 
SIP-I interworking is applicable in the originating network, a ISUP IAM is 
encapsulated in the initial INVITE request. 

Ensure that all the mandatory parameters in the IAM are present and the values 
are valid and the Transmission medium requirement parameter is consistent 
with the SDP. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Nature of connection indicators 
Forward call indicators 
Calling party's category 
Transmission medium requirement 
Called party number 
Calling party number (optional) 
Optional forward call indicators (optional) 
Hop counter (optional) 
User service information (optional) 
Access transport (optional) 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
100 Trying 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is an ISUP IAM encapsulated in the INVITE request? 
Check: Are all the mandatory ISUP parameters present in the IAM and are the 
values valid? 

Check: Are the values of the optional parameters in the encapsulated IAM 
valid? 

Check: Is the 'm' line with corresponding attributes in the SDP consistent with 
the Transmission medium requirement parameter? 

Check: Is the Transmission medium requirement value consistent with the 
bandwidth information in the SDP? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 034 


Test case group 


BCALL/successful 


Reference 


7.2.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 4 AND SE 1 7 AND SE 47 


Test purpose 


SIP-I support, Basic call, overlap signalling. 

Ensure that when overlap signalling applies in the ISUP -SIP-I interworking in the 
originating network, several INVITE requests with the same Cal-ID and From tag 
are sent from Network A to Network B. 

Ensure that the original IAM is encapsulated in any INVITE request. 


Configuration 




SIP Parameter 




Message flow 


SIP (Network A) 


Interconnection Interface 

INVITE(1) 
4- 484 Address Incomplete^ ) 
ACK 
INVITE(2) 
4- 484 Address Incomplete^) 
ACK 
INVITE(3) 
4- 484 Address Incomplete^) 
ACK 


SIP (Network B) 




INVITE(4) 
180 Ringing(4) 
Apply post test routine 




Comments 


Establish a communication from network A to Network B using the overlap 
procedure in Network A 

Check: Are the INVITE requests sent with the same From tag and the Call-ID? 
Check: After the 180 applies, are all previous INVITE transactions are 

terminated with a 484 final response? 
Check: Is the encapsulated IAM present in the initial INVITE request also 

encapsulated in any following INVITE request required for the call 

setup? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 035 


Test case group 


BCALL/successful 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support, Basic call, ACM present in the 180 response. 

Ensure that on receipt of a 180 Ringing provisional response and an 

SIP-I - ISUP interworking is applicable in the terminating network the Backward 

call indicators parameter in the encapsulated ACM is present and the values are 

valid. 

Ensure that the values of the optional parameters in the encapsulated ACM are 
valid. 


Configuration 




SIP Parameter 


180: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicators 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
180 Ringing(ACM) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is an ISUP ACM message encapsulated in the 180 Ringing provisional 
response? 

Check: Is the mandatory Backward call indicators parameter present in the 
encapsulated ISUP ACM and are the values valid? 

Check: Are the values of optional parameters in the encapsulated ISUP ACM 
valid? 

Check: If an SDP answer is present in the 180, are the codec and the 

bandwidth information in the 'a' attributes consistent with Transmission 
medium requirement in the encapsulated IAM of the INVITE request? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 036 


Test case group 


BCALL/successful 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, early ACM present in the 183 response. 

Ensure that on receipt of a 183 Session Progress provisional response and an 

SIP-I - ISUP interworking is applicable in the terminating network the Backward 

call indicators parameter in the encapsulated ACM is present and the value of 

the Called party's status indicator is set to no indication'. 

Ensure that the values of the optional parameters in the encapsulated ACM are 

valid. 


Configuration 


Select a proper destination that sends an early ACM in the PSTN/PLMN e.g. 
announcement 


SIP Parameter 


183: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicators 

Called party's status indicator no indication 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
1 83 Session Progress(ACM) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is an ISUP ACM message encapsulated in the 183 Session Progress 

provisional response? 
Check: Is the mandatory Backward call indicators parameter present in the 

encapsulated ISUP ACM and are the values valid? 
Check: Is the Called party's status indicator in the encapsulated ISUP ACM 

set to 'no indication'? 
Check: Are the values of optional parameters in the encapsulated ISUP ACM 

valid? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 037 


Test case group 


BCALL/successful 


Reference 


6.6/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, CPG present in a 180 response. 

Ensure that on receipt of a 180 Ringing provisional response and an 

SIP-I - ISUP interworking is applicable in the terminating network the Event 

indicator in the encapsulated CPG is present and set to 'ALERTING'. 

Ensure that the values of the optional parameters in the encapsulated CPG are 

valid. 


Configuration 


Select a proper destination that sends at first an early ACM and after then a 
CPG 'ALERTING' in the PSTN/PLMN (e.g. PBX). 


SIP Parameter 


180: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Event indicator = ALERTING 
-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
1 83 Session Progress(ACM) 

180 Ringing(CPG) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is an ISUP CPG message encapsulated in the 180 Ringing provisional 
response? 

Check: Is the mandatory Event indicator present in the encapsulated ISUP 

CPG set to 'ALERTING'? 
Check: Are the values of optional parameters in the encapsulated ISUP CPG 

valid? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 038 


Test case group 


BCALL/successful 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, ANM present in a 200 OK INVITE response. 

Ensure that on receipt of a 200 OK INVITE final response and an SIP-I - ISUP 
interworking is applicable in the terminating network the ISUP ANM is 
encapsulated in the 200 OK. 

Ensure that the values of the optional parameters in the encapsulated ANM are 
valid. 


Configuration 




SIP Parameter 


180: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
180 Ringing(ACM) 
200 OK INVITE(ANM) 
ACK 

Apply post test routine 


Comments 


Establish a confirmed communication from network A to Network B 
Check: Is an ISUP ANM encapsulated in the 200 OK INVITE? 
Check: Are the values of optional parameters in the encapsulated ISUP ANM 
valid? 

Check: Ensure the property of speech. 

Check: Are the codec and the bandwidth information in the 'a' attributes 

consistent with Transmission medium requirement in the encapsulated 
IAM of the INVITE request? 

Repeat this test in reverse direction. 
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Test case number 


SS bcall 039 


Test case group 


BCALL/successful 


Reference 


5.4.3.4, 6.11.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support. Basic call, REL present in a BYE request sent from the 
originating network. 

Ensure that a ISUP REL message is encapsulated in a BYE request sent in the 

release procedure initiated from the originating user when ISUP - SIP-I 

interworking is applicable in the originating network. 

Ensure the validity of the cause indicator in the encapsulated REL. 

Ensure that the ISUP RLC is encapsulated in the 200 OK BYE. 


Configuration 




SIP Parameter 


BYE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 

-[any boundary narne]-- 
200 OK BYE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

RLC 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE(REL) 
200 OK BYE(RLC) 


Comments 


Establish a confirmed communication from network A to Network B 

The originating user terminates the communication 

Check: Is the ISUP REL encapsulated in the BYE request? 

Check: Are the cause indicators in the encapsulated ISUP REL valid? 

Check: If a Reason header is present in the BYE request, is the 'cause' value 

of Reason header equal to the 'Cause value' in the encapsulated 

REL? 

Check: Is the ISUP RLC encapsulated in the 200 OK BYE? 
Repeat this test in reverse direction. 
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Test case number 


SS bcall 040 


Test case group 


BCALL/successful 


Reference 


5.4.3.4, 6.11.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support. Basic call, REL present in a BYE request sent from the 
terminating network. 

Ensure that a ISUP REL message is encapsulated in a BYE request sent in the 

release procedure initiated from the terminating user when SIP-I - ISUP 

interworking is applicable in the terminating network. 

Ensure the validity of the cause indicator in the encapsulated REL. 

Ensure that the ISUP RLC is encapsulated in the 200 OK BYE. 


Configuration 




SIP Parameter 


BYE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 

-[any boundary narne]-- 
200 OK BYE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

RLC 

-[any boundary name]- 


Message flow 


SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
100 Trying 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE(REL) 
200 OK BYE(RLC) 


Comments 


Establish a confirmed communication from network A to Network B 

The terminating user terminates the communication 

Check: Is the ISUP REL encapsulated in the BYE request? 

Check: Are the cause indicators in the encapsulated ISUP REL valid? 

Check: If a Reason header is present in the BYE request, is the 'cause' value 

of Reason header equal to the 'Cause value' in the encapsulated 

REL? 

Check: Is the ISUP RLC encapsulated in the 200 OK BYE? 
Repeat this test in reverse direction. 
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7. 1 .2 Codec negotiation 



Test case number 


SS_codec_001 


Test case group 


BCALL/Codec Negotiation 


Reference 


[3], [4] and [5] 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the calling user. 

During the session, the calling user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE or UPDATE 
containing a new media description. This re-INVITE or UPDATE references the 
existing dialog so that the other party knows that it is to modify an existing 
session instead of establishing a new session. The other party sends a 200 (OK) 
to accept the change. The requestor responds to the 200 (OK) with an ACK. 
In case when the parameter in the SDP rtpmap:<dynamic-PT> is used the 
codecs in table 7.1 .2-1 applies. 


Configuration 




SIP Parameter 


SDP1 : codec x chosen from table 7.1 .2-1 
SDP3: codec y chosen from table 7.1 .2-1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session already exists (SDP 1) 
CASE A INVITE(SDP3) 

200 OK INVITE(SDP4) 
ACK 

CASE B UPDATE(SDP3) 

200 OK UPDATE(SDP4) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B using SDP1 chosen 
from the table 7.1.2-1 

Check: The calling user changes the media description using INVITE request 
containing SDP 3 codec chosen from table 7.1 .2-1 different to SDP1 . 

Check: Is the codec list consistent with the attribute(s) (bandwidth) regarding 
the media description? 

Repeat this test in reverse direction. 



ETSI 



45 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS codec 002 


Test case group 


BCALL/Codec Negotiation 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the called user. 

During the session, the called user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE containing a new 
media description. This re- INVITE references the existing dialog so that the 
other party knows that it is to modify an existing session instead of establishing a 
new session. The other party sends a 200 (OK) to accept the change. 
The requestor responds to the 200 (OK) with an ACK. 
In case when the parameter in the SDP rtpmap:<dynamic-PT> is used the 
codecs in table 7.1 .2-1 applies. 


Configuration 




SIP Parameter 


SDP1 : codec x chosen from table 7.1 .2-1 
SDP2: codec y chosen from table 7.1 .2-1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session already exists (SDP 1) 
CASE A INVITE(SDP3) 

200 OK INVITE(SDP4) 
ACK 

CASE B UPDATE(SDP3) 

200 OK UPDATE(SDP4) 
Apply post test routine 


Comments 


Establish a connection from SIP UE 1 to SIP UE 2 using SDP1 chosen from the 
table 7.1.2-1 

Check: The called user changes the media description using INVITE request 
containing SDP 2 codec chosen from table 7.1 .2-1 different to SDP1 . 

Check: Is the codec list consistent with the attribute(s) (bandwidth) regarding 
the media description? 

Repeat this test in reverse direction. 



Test case number 


SS_codec_003 


Test case group 


BCALL/Codec Negotiation 


Reference 


[3], [4] and [5] 


SELECTION EXPRESSION 




Test purpose 


The SDP answer is contained in a 200 OK final response. 

Ensure that the call establishment performed correctly. 

• The initial INVITE contains a SDP with the offer 1 . 

• Ensure that answer related to the SDP offer is contained in the 200 
OK INVITE message. 

Ensure that in the confirmed call state the voice transfer on the media channels 
is performed correctly. 


Configuration 




SIP Parameter 


INVITE: SDP offer 
200: SDP answer 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(SDPI) 
180 Ringing 
200 OK INVITE(SDP2) 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B 
Check: Is the SDP offer contained in the initial INVITE request? 
Check: Is the SDP answer contained in the 200 OK INVITE final response? 
Repeat this test in reverse direction. 



ETSI 



46 



ETSI TS 101 585 V1.1.1 (2012-08) 



Table: 7.1.2-1 
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7.1.3 Resource Reservation 



Test case number 


SS_resource_001 


Test case group 


BCALL/Resource Reservation 


Reference 


[3], [4], [5] and [6] 


SELECTION EXPRESSION 


([Network A] SE 50 AND [Network B] SE 50) AND SE 7 


Test purpose 


Resource reservation successful, segmented status. 

Ensure that the network is able to reserve resources for quality of service when 
requested from the initiating user. 

• In the INVIT the UE requests to establish QoS preconditions for all the 
media streams. 

• In the 183 Session Progress the UAS supports the QoS preconditions 
and requests that UAC sends a confirmation when the QoS 
preconditions are met. 

• The UPDATE includes in the SDP the information about the successful 
QoS bidirectional mode, due to the successful bidirectional PDP context 
established. 

• 200 OK UPDATE the SDP contains an indication that the UE 
successfully reserved the QoS in the send and receive directions. 


Configuration 




SIP Parameter 


INVITE: Supported: 1 0Orel precondition 
SDP1 : m=audio 3456 RTP/AVP 8 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

183 Session Progress: Supported: 1 0Orel precondition 
SDP2: m=audio 6544 RTP/AVP 8 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 




UPDATE 

SDP3: m=audio 3456 RTP/AVP 8 
a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

200 OK UPDATE 

SDP4: a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(SDPI) 
1 83 Session Progress(SDP2) 
PRACK 
200 OK PRACK 
Resource reservation 

UPDATE(SDP3) 
200 OK UPDATE(SDP4) 
Apply post test routine 


Comments 


Establish a communication from network A to Network B 

Check: Is the quality of service for the current state local and remote set to 

'none' indicated in the SDP in the INVITE? 
Check: Is the quality of service for the desired state local and remote set to 

'mandatory' and 'sendrecv' in the 183? 
Check: Is the quality of service for the current state local set to 'sendrecv' 

indicated in the SDP in the UPDATE? 
Check: Is the quality of service for the current state local and remote set to 

'sendrecv' indicated in the SDP in the 200 OK UPDATE? 
Repeat this test in reverse direction. 
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7.1 .4 Test purposes for SIP-SIP, Basic call, Unsuccessful 



Test case number 


SS_unsucc_001 


Test case group 


BCALL/unsuccessful 


Reference 


[4] 


SELECTION EXPRESSION 




Test purpose 


Called number is not allocated in the assumed network. 

Ensure that, when calling to unallocated number, the network initiate call clearing 
to the calling user with a 404 Not Found message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
404 Not Found 
ACK 


Comments 


Establish a communication from network A to Network B, called user number is 
not allocated in Network B 

Check: Is a 404 Not Found sent from Network B to Network A? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 




Test case number 


SS_unsucc_002 


Test case group 


BCALL/unsuccessful 


Reference 


[4] 


SELECTION EXPRESSION 




Test purpose 


The network B is unable to process the request. 

Ensure that the call will be released if the Service unavailable. The network 
initiates call clearing to the calling user with a 503 Service unavailable message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
503 Service unavailable 
ACK 


Comments 


Establish a communication from network A to Network B, Network B is unable to 
process the request. 

Check: Is a 503 Service unavailable sent from Network B to Network A? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 




Test case number 


SS_unsucc_003 


Test case group 


BCALL/unsuccessful 


Reference 


[4] 


SELECTION EXPRESSION 




Test purpose 


The called user is network determined busy. 

Ensure that, when the called user is busy, the network initiates call clearing to 
the calling user with a 486 Busy Here message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
486 Busy Here 
ACK 


Comments 


Establish a communication from network A to Network B, user B is network 
determined user busy. 

Check: Is a 486 Busy Here sent from Network B to Network A? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 004 I 


Test case group 


BCALL/unsuccessful 


Reference 


r ai 

[4] 


obLbO I IUN bArnbbolUN 




Test purpose 


The called user is user determined busy. 

Ensure that, when the called user is busy, the user initiates call clearing to the 
calling user with a 486 Busy Here message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
486 Busy Here 
ACK 


Comments 


Establish a communication from network A to Network B, user B is user 
determined user busy. 

Check: Is a 486 Busy Here sent from Network B to Network A 
Repeat this test in reverse direction. 



Test case number 


SS unsucc 005 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The called user is not available under the called number. 

Ensure that when the number is changed, the network initiate call clearing 
to the calling user with a 410 Gone message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
410 Gone 
ACK 


Comments 


Establish a communication from network A to Network B, user B is not 
allocated in Network B. 

Check: Is a 41 Gone sent from Network B to Network A? 
Repeat this test in reverse direction. 



Test case number 


SS unsucc 006 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


The number of the called user is incomplete. 

Ensure that the call will be released when the called number is incomplete. The 
network initiates call clearing to the calling user with 484 Not Found message. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

4- 484 Address Incomplete 
ACK 


Comments 


Establish a communication from network A to Network B, the called number is 
incomplete. 

Check: Is a 484 Address Incomplete sent from Network B to Network A? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 007 


Test case group 


BCALL/unsuccessful 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the calling user is unsuccessful, existing 
session remains unchanged. 

During the session, the calling user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE containing a new 
media description. This re-INVITE references the existing dialog so that the other 
party knows that it is to modify an existing session instead of establishing a new 
session. Ensure that if the other party does not accept the change, he sends an 
error response such as 488 Not Acceptable Here, which also receives an ACK. 
The session remains unchanged. 


Configuration 




SIP Parameter 


INVITE: codec not supported in Network B 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
INVITE 
488 Not Acceptable Here 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B. 

User A in Network A attempts to change the session by sending a SDP offer to 

the UE in Network B. 

Network B does not support the codec sent in the offer. 

Check: Is a 488 Not Acceptable Here sent from Network B to Network A? 

Repeat this test in reverse direction. 
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Test case number 


SS unsucc 008 


Test case group 


BCALL/unsuccessful 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Session update requested by the called user is unsuccessful, existing 
session remains unchanged. 

During the session, the called user decides to change the characteristics of the 
media session. This is accomplished by sending a re-INVITE containing a new 
media description. This re-INVITE references the existing dialog so that the other 

■ 1 ■ 1 ■ ■ ■ * ■ 1 ■ r ■ ■ ■ ■ ■ ■ 1 r ■ 1 1 1 1 1 

party knows that it is to modify an existing session instead of establishing a new 
session. Ensure that if the other party does not accept the change, he sends an 
error response such as 488 Not Acceptable Here, which also receives an ACK. 
The session remains unchanged. 

The 488 Not Acceptable Here may be sent by a simulation equipment. 


Configuration 




SIP Parameter 


INVITE: codec not supported in Network A 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
INVITE 
488 Not Acceptable Here 
ACK 

Apply post test routine 


Comments 


Establish a communication from network A to Network B. 

User B in Network B attempts to change the session by sending a SDP offer to 

the UE in Network A 

Network A does not support the codec sent in the offer. 

Check: Is a 488 Not Acceptable Here sent from Network B to Network A? 

Repeat this test in reverse direction. 




Test case number 


SS_unsucc_009 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


Call clearing due to no answer from the called user initiated by the calling 
user. 

Ensure that when there is no answer from the called user, the calling user 
initiates call clearing to the called user with CANCEL or BYE 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
CANCEL/BYE 
200 OK CANCEL/BYE 
4- 487 Request Terminated 
ACK 


Comments 


Check: Is a CANCEL or BYE request is sent from the originating user? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 010 


Test case group 


BCALL/unsuccessful 


Reference 


[31, [41 and [51 


SELECTION EXPRESSION 




Test purpose 


Codec not supported by the called user. 

The initial INVITE contains a SDP with codes that does not support by the called 
user. 

Ensure that, when the called user does not accept the Media session, the called 
user initiate call clearing to the calling user with 488 Not Acceptable Here, which 
also receives an ACK. 


Configuration 




SIP Parameter 


INVITE: codec not supported at user (Network B) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

488 Not Acceptable Here 
ACK 


Comments 


Establish a call setup from network A to Network B. 

User B in Network B does not support the codec offered in the SDP received 
from Network A. 

Check: Is a 488 Not Acceptable Here sent from Network B to Network A. 
Repeat this test in reverse direction. 




Test case number 


SS_unsucc_01 1 


Test case group 


BCALL/unsuccessful 


Reference 


[41 


SELECTION EXPRESSION 




Test purpose 


Call clearing due to no answer from the called user initiated by the 
originating network. 

Ensure that when there is no answer from the called user, the originating 
network initiate the call clearing after timeout of SIP timer C and sends a 
CANCEL or BYE to the called user. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Start timer C 

Timeout timer C 

CANCEL/BYE 
200 OK CANCEL/BYE 
4- 487 Request Terminated 
ACK 


Comments 


Check: Is a CANCEL or BYE request is sent by the originating network? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 012 I 


Test case group 


BCALL/unsuccessful 


Reference 


6.11.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 


Test purpose 


SIP-I support. Called number is not allocated in the PSTN/PLMN network. 

Ensure that, when calling to an unallocated number in the PSTN/PLMN part of 
network B and ISUP - SIP-I interworking applies in Network B, the network 
initiate call clearing to the calling user with a 404 Not Found message. A ISUP 
REL message is encapsulated and the Cause value indicator is set to '1'. 


Configuration 


The called user number is not assigned to the PSTN/PLMN part in Network B 


SIP Parameter 


404: 

Reason: Q.850;cause=1 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 1 

-[any boundary name]- 


Message flow 
SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 
404 Not Found(REL) 
ACK 


Comments 


Establish a communication from network A to Network B, called user number is 

not allocated in the PSTN/PLMN part of Network B 

Check: Is a 404 Not Found sent from Network B to Network A? 




Check: is a ISUP REL encapsulated and the Cause value indicator is set to 
'1'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 013 I 


Test case group 


BCALL/unsuccessful 


Reference 


6.11.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support. The called user is busy. 

Ensure that, when the called user in the PSTN/PLMN part of Network B and 
ISUP - SIP-I interworking applies in Network B is busy, the network initiates call 
clearing to the calling user with a 486 Busy Here message. A ISUP REL 
message is encapsulated and the Cause value indicator is set to '17'. 


Configuration 


The called user is busy in the PSTN/PLMN part in Network B 


SIP Parameter 


486: 

Reason: Q.850;cause=17 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 17 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 
486 Busy Here(REL) 
ACK 


Comments 


Establish a communication from network A to Network B, user B in the 
PSTN/PLMN part of Network B is busy. 

Check: Is a 486 Busy Here sent from Network B to Network A? 
Check: Is a ISUP REL encapsulated and the Cause value indicator is set to 
'17'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 014 


Test case group 


BCALL/unsuccessful 


Reference 


6.11.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support. The called user rejects the call. 

Ensure that, when the called user in the PSTN/PLMN part of Network B and 
ISUP - SIP-I interworking applies in Network B rejects the communication setup, 
the network initiates call clearing to the calling user with a 480 Temporarily 
Unavailable final response. A ISUP REL message is encapsulated and the 
Cause value indicator is set to '21'. 


Configuration 




SIP Parameter 


480: 

Reason: Q.850;cause=21 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 21 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 

480 Temporarily Unavailable (REL) 
ACK 


Comments 


Establish a communication from network A to Network B, user B in the 
PSTN/PLMN part of network B rejects the communication setup. 
Check: Is a 480 Temporarily Unavailable sent from Network B to Network A? 
Check: is a ISUP REL encapsulated and the Cause value indicator is set to 
'21'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 015 


Test case group 


BCALL/unsuccessful 


Reference 


7.7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support. Call clearing due to no answer from the called user initiated 
by the calling user. 

Ensure when the early dialogue is not confirmed by the called user, the calling 
user located in the PSTN/PLMN part of Network A and ISUP - SIP-I interworking 
applies in Network A initiates call clearing to the called user with CANCEL or 
BYE. An ISUP REL message is encapsulated in the BYE request and the Cause 
value indicator is set to '16'. 


Configuration 




SIP Parameter 


480: 

Reason: Q.850;cause=16 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 16 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 

CASE A 

CANCEL 
200 OK CANCEL 
4- 487 Request Terminated 
ACK 

CASE B 

BYE(REL) 
200 OK BYE(RLC) 
4- 487 Request Terminated 
ACK 


Comments 


Establish a communication from network A to Network B, user B does not 
confirm the communication. 

The originating user in the PSTN/PLMN part of Network A terminates the early 
dialogue. 

Check: Is a CANCEL or BYE request is sent from the originating network? 

Check: Is a ISUP REL encapsulated in a BYE request? 

Check: Is the Cause value of the encapsulated REL set to '1 6'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 

NOTE: A ISUP REL is not encapsulated in a CANCEL request. 
Repeat this test in reverse direction. 
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Test case number 


SS unsucc 016 I 


Test case group 


BCALL/unsuccessful 


Reference 


7.7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 


Test purpose 


SIP-I support. Call clearing due to no answer from the called user initiated 
by the originating network. 

Ensure when the early dialogue is not confirmed by the called user, the 
originating network initiate the call clearing after timeout of ISUP timer T9 if the 
calling user is located in the PSTN/PLMN part of Network A and ISUP - SIP-I 
interworking applies in Network A and the originating network sends a CANCEL 
or BYE to the called user. An ISUP REL message is encapsulated in the BYE 
request and the Cause value indicator is set to '19'. 


Configuration 




SIP Parameter 


480: 

Reason: Q.850;cause=19 (optional) 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value: 19 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Start timer T9 


CASE A 


Timeout T9 

CANCEL 
200 OK CANCEL 
4- 487 Request Terminated 
ACK 


CASE B 


BYE(REL) 
200 OK BYE(RLC) 
4- 487 Request Terminated 
ACK 


Comments 


Establish a communication from network A to Network B, user B does not 

answer the communication setup. 

The ISUP timer T9 in the PSTN/PLMN expires 

Check: Is a CANCEL or BYE request is sent by the originating network? 

Check: Is a ISUP REL encapsulated in a BYE request? 

Check: Is the Cause value of the encapsulated REL set to '1 9'? 

Check: If a Reason header is present, is the cause value equal to the value in 

the Cause value of the encapsulated ISUP REL? 
Check: Is a 487 Request Terminating send from the terminating user? 
Check: Are the media streams terminated after the 200 OK CANCEL/BYE 

was sent? 

NOTE: A ISUP REL is not encapsulated in a CANCEL request. 
Repeat this test in reverse direction. 
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7.1 .5 Test purposes for Supplementary services 



7.1 .5.1 Test purposes for OIP 



Test case number 


SS_oip_001 


Test case group 


SIP-SIP/Service/OIP 


Reference 


5.2.6.3/[2] 


SELECTION EXPRESSION 




Test purpose 


No P-Preferred-ldentity received. The terminating user receives the default 
public user identity of the originating user. 

In case the preconditions are fulfilled to provide the terminating UE with 
originating identification information without preventing the presentation, ensure 
that no identity information in the P-Preferred-ldentity header is provided by the 
originating UE, the terminating user receives a P-Asserted-ldentity based on 
the default public user identity associated with the originating UE identifies the 
originator of the session. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity= default public user identity 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 


Comments 


Check: Is the P-Asserted-ldentity set to the default public user identity? 
Check: Is optional a second P-Asserted-ldentity header present as a 'tel' URI 

with a public user identity? 
Check: Is the user parameter is set to phone? 
Repeat this test in reverse direction. 
Repeat this test with all relevant end devices. 



Test case number 


SS oip 002 


Test case group 


SIP-SIP/Service/OIP 


Reference 


5.2.6.3/[2] 


SELECTION EXPRESSION 




Test purpose 


P-Preferred-ldentity received, no match with the set of registered public 
identities. The terminating user receives the default public user identity of 
the originating user. 

In case the preconditions are fulfilled to provide the terminating UE with 
originating identification information without preventing the presentation, ensure 
that an identity information in the P-Preferred-ldentity header is provided by the 
originating UE, does not match with the set of registered public identities of the 
originating UE the terminating user receives a P-Asserted-ldentity based on the 




originator of the session. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity= default public user identity 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 


Comments 


Check: Is the P-Asserted-ldentity set to the default public user identity? 
Check: Is optional a second P-Asserted-ldentity header present as a 'tel' URI 

with a public user identity? 
Check: Is the user parameter is set to phone? 
Check: Is the P-Preferred-ldentity header not present? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 
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Test case number 


SS oip 003 


Test case group 


SIP-SIP/Service/OIP 


Reference 


5.2.6.3/[2] 


SELECTION EXPRESSION 




Test purpose 


P-Preferred-ldentity received, match with the set of registered public 
identities. The terminating user receives the registered public user identity 
of the originating user. 

In case the preconditions are fulfilled to provide the terminating UE with 
originating identification information without preventing the presentation, ensure 
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that an identity information in the P-Preferred-ldentity header is provided by the 
originating UE, matches with the set of registered public identities of the 
originating UE the terminating user receives a P-Asserted-ldentity based on the 




information provided by the originating UE identifies the originator of the session. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity= matched public user identity' 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 


Comments 


Check: Is the P-Asserted-ldentity set to the identified public user identity? 
Check: Is optional a second P-Asserted-ldentity header present as a 'tel' URI 

with a public user identity? 
Check: Is the user parameter is set to phone? 
Check: Is the P-Preferred-ldentity header not present? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 




Test case number 


SS oip 004 


Test case group 


SIP-SIP/Service/OIP 


Reference 


4.5.2.4/[7] 


SELECTION EXPRESSION 


SE 18 AND NOTSE 19 


Test purpose 


No Special arrangement exists. 

The special arrangement does not exist (screening of user provided information). 
The network compares the information in the From header with the set of 
registered public identities of the originating user If is no match is found, the AS 
sets the From header to the SIP URI that includes the registered default public 
user identity. 


Configuration 


Special arrangement for the originating user does not exist 


SIP Parameter 


INVITE 

From=default public user identity 
P-Asserted-Header=[any registered public user identity] 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 


Comments 


Check: Is the From header URI set to the value of the P-Asserted-ldentity 
URI? 

Check: Is the P-Asserted-ldentity set to any registered public user identity? 
Check: Is the user parameter is set to phone? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 
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Test case number 


SS oip 005 


Test case group 


SIP-SIP/Service/OIP 


Reference 


4.5.2.4/[7] 


SELECTION EXPRESSION 


SE 18 AND SE 19 


Test purpose 


Special arrangement exists. 

The special arrangement exists (no screening of user provided information). The 
network does not attempt to match the information in the From header with the 
set of registered public identities of the originating user. The From header field is 
transparently transported to the terminating user. 


Configuration 


Special arrangement for the originating user exists 


SIP Parameter 


INVITE 

From= original value 

P-Asserted-Header=[any registered public user identity] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 


Comments 


Check: Is the From header URI set to original value sent by the user? 
Check: Is the P-Asserted-ldentity set to any registered public user identity? 
Check: Is the user parameter is set to phone? 
Repeat this test in reverse direction. 
Repeat this test with all relevantend devices. 
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Test case number 


SS oip 006 


Test case group 


SIP-SIP/Service/OIP 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Calling party number presentation allowed \n the 
encapsulated IAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP IAM is encapsulated in the INVITE request. The P-Asserted- 
Identity header field is derived from the Calling party number in the encapsulated 
IAM. The 'Presentation restriction' indicator in the encapsulated IAM is set to 
'allowed' no Privacy value 'id' is present in the INVITE request. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity=[derived from the ISUP calling party number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Calling party number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 


Comments 


Check: Is a BICC/ISUP IAM encapsulated in the in the INVITE request? 

Check: Is the Calling party number present in the encapsulated IAM and the 
screening indicator is set to 'Network provided' or 'user provided, 
verified and passed' and the Presentation restriction indicator is set to 
'allowed'? 

Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated IAM? 
Check: Is the value 'id' not present in the Privacy header field (if included)? 
Repeat this test in reverse direction. 
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Test case number 


SS oip 007 I 


Test case group 


SIP-SIP/Service/OIP 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Additional Calling party number presentation allowed 
in the encapsulated IAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP IAM is encapsulated in the INVITE request. The From field is 
derived from the Additional Calling party number in the encapsulated IAM. The 
'Presentation restriction' indicator in the encapsulated IAM is set to 'allowed' no 
Privacy value 'id' is present in the INVITE request. 


Configuration 


The originating user in the PSTN/PLMN part of Network A is subscribed to the 
'no screening option' 


SIP Parameter 


INVITE 

From=[derived from the ISUP Additional calling party number] 
P-Asserted-ldentity=[derived from the ISUP calling party number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Calling party number 
Screening indicator 

Network Provided 
Presentation restriction 

allowed 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Presentation restriction 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 


Comments 


Check: Is a BICC/ISUP IAM encapsulated in the in the INVITE request? 
Check: Is the Calling party number present in the encapsulated IAM and the 

screening indicator is set to 'Network Provided' and the Presentation 

restriction indicator is set to 'allowed'? 
Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated IAM? 
Check: Is a Generic number parameter, Number Qualifier Indicator set to 

Additional calling party number present and the screening indicator 

is set to 'user provided, not verified' and the Presentation restriction 

indicator is set to 'allowed'? 
Check: Is the From header field derived from the Additional calling party 

number in the encapsulated IAM? 
Check: Is the value 'id' not present in the Privacy header field (if included)? 
Repeat this test in reverse direction. 



ETSI 



63 



ETSI TS 101 585 V1.1.1 (2012-08) 



7.1 .5.2 Test purposes for OIR 



Test case number 


SS oir 001 


Test case group 


SIP-SIP/Service/OIR 


Reference 


4.3.2, 4.5.2.4/ [7] 


SELECTION EXPRESSION 


SE20 


Test purpose 


Terminating user does not receive the identity of the originating user. 

In case the preconditions are fulfilled not to provide the terminating UE with 
originating identification information (e.g. permanent mode ), ensure that the P- 
Asserted-ldentity still contains identity information and the privacy is set to 'id' or 
'header' or 'user'. The terminating user does not receive the identity of the 
originating user. 

As a network option, the From header is set to an anonymous User Identity. 


Configuration 


Originating user subscribes to the OIR service 


SIP Parameter 


INVITE 

P-Asserted-ldentity: 
Privacy:id OR header OR user 

From: <sip:anonymous@anonymous.invalid> (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 


Comments 


Check: Is the P-Asserted-ldentity is present? 

Check: Is the Privacy header set to 'id' or 'header' or 'user'? 

Check: Is optional the From header set to an anonymous User Identity? 

Repeat this test in reverse direction. 

Repeat this test with all chosen end devices. 




Test case number 


SS oir 002 


Test case group 


SIP-SIP/Service/OIR 


Reference 


4.3.2, 4.5.2.4/[7] 


SELECTION EXPRESSION 


SE 20 AND SE 25 


Test purpose 


Communication forwarding unconditional, served user subscribes OIR. 

The user A and user C are in network B and user C is provided with OIP. The 
user B is in network A and is provided with CFU "diverting number is released to 
the diverted-to user"=Yes. 

In case the served user subscribes Originating Identification Restriction (e.g. 
permanent mode), ensure that when user A calls user B, the call is forwarded 
unconditional to user C, user C is not informed of the forwarding number. The 
diverted-to user receives no identity of the diverting user neither in a History-Info 
header nor in the To header. 


Configuration 


Diverting user subscribes to the OIR service 


SIP Parameter 


INVITE: no history entry present 
INVITE: 

History-Info header: 

<sip:userB@networkA?Privacy=history >;index=1 , 
<sip: userC@networkB;cause=302 >;index=1.1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

CFU is performed in Network A 
INVITE 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE from Network B. 
Check: Is the Privacy value history is escaped in the hi-targed-to-uri of the 

diverting user in Network A? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS oir 003 


Test case group 


SIP-SIP/Service/OIR 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Calling party number presentation restricted in the 
encapsulated IAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP IAM is encapsulated in the INVITE request. The 
P- Asserted- Identity header field is derived from the Calling party number in the 
encapsulated IAM. The 'Presentation restriction' indicator in the encapsulated 
IAM is set to 'restricted' the value 'id' is present in the Privacy header of the 
INVITE request. 


Configuration 




SIP Parameter 


INVITE 

P-Asserted-ldentity=[derived from the ISUP calling party number] 
Privacy: id 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Calling party number 
Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 


Comments 


Check: Is a BICC/ISUP IAM encapsulated in the in the INVITE request? 

Check: Is the Calling party number present in the encapsulated IAM and the 
screening indicator is set to 'Network provided' or 'user provided, 
verified and passed' and the Presentation restriction indicator is set to 
'restricted'? 

Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated IAM? 
Check: Is the value 'id' present in the Privacy header field? 
Repeat this test in reverse direction. 
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Test case number 


SS oir 004 I 


Test case group 


SIP-SIP/Service/OIR 


Reference 


7.1.3/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 52 


Test purpose 


SIP-I support. ISUP Additional Calling party number presentation restricted 
in the encapsulated IAM. 

Ensure when BICC/ISUP - SIP-I interworking applies in the originating network 
the BICC/ISUP IAM is encapsulated in the INVITE request. The From field is 
derived from the Additional Calling party number in the encapsulated IAM. The 
'Presentation restriction' indicator in the Generic number parameter is set to 
'allowed' no Privacy value 'id' is present in the INVITE request. 


Configuration 


The originating user in the PSTN/PLMN part of Network A is subscribed to the 
'no screening option' 


SIP Parameter 


INVITE 

P-Asserted-ldentity=[derived from the ISUP calling party number] 
From=[derived from the ISUP Additional calling party number] 

Privacy: id 

Content-Type: multipart/mixed;boundary=[any boundary name] 
--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Calling party number 
Screening indicator 

Network Provided 
Presentation restriction 

restricted 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Presentation restriction 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 


Comments 


Check: Is a BICC/ISUP IAM encapsulated in the in the INVITE request? 
Check: Is the Calling party number present in the encapsulated IAM and the 

screening indicator is set to 'Network Provided' and the Presentation 

restriction indicator is set to 'restricted'? 
Check: Is the P-Asserted-ldentity header field derived from the Calling party 

number in the encapsulated IAM? 
Check: Is a Generic number parameter, Number Qualifier Indicator set to 

Additional calling party number present and the screening indicator 

is set to 'user provided, not verified' and the Presentation restriction 

indicator is set to 'restricted'? 
Check: Is the From header field derived from the Additional calling party 

number in the encapsulated IAM? 
Check: Is the value 'id' present in the Privacy header field? 
Repeat this test in reverse direction. 
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7.1 .5.3 Test purposes for TIP 



Test case number 


SS_tip_001 


Test case group 


SIP-SIP/Service/TIP 


Reference 


5.2.6.4/[8] 


SELECTION EXPRESSION 




Test purpose 


Originating user receives the identity of the terminating user. 

Ensure in case the preconditions are fulfilled to provide the originating UE with 
tprminatino iripntifination information without orpvpntino thp orp^pntation thp 
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originating UE receives in a 1xx or 200 SIP response a P-Asserted-ldentity 
header field with a valid public user identity of the terminating UE. 


Configuration 




SIP Parameter 


18x/200 OK INVITE 

P-Asserted-ldentity: 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 


CASE A 


180 Ringing 


CASE B 


183 Session Progress 


CASEC 


200 OK INVITE(P-Asserted-ldentity) 
Apply post test routine 


Comments 


Check: Is the P-Asserted-ldentity is present in a 180 Ringing or 183 Session 

Progress or in a 200 OK INVITE? 
Repeat this test in reverse direction. 
Repeat this test with all relevant end devices. 
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Test case number 


SS tip 002 


Test case group 


SIP-SIP/Service/TIP 


Reference 


4.5.2.9/[8] 


SELECTION EXPRESSION 


SE 21 AND SE 22 AND [Network B] SE 48 


Test purpose 


Second identity provided in UPDATE. 

Ensure that, when the option tag "from-change" in the Supported header field 
is provided by the originating UE in the INVITE request and the terminating UE 
receives the from-change tag, The terminating user sends a 'from-change' tag in 
the supported header in the 200 OK INVITE a second identity is provided in the 
UPDATE request sent by the terminated user in the From header after the ACK 
was received. 


Configuration 


Special arrangement for the terminating user exists 


SIP Parameter 


INVITE 

Supported: from-change 

200 OK INVITE 

P-Asserted-ldentity: 

UPDATE 

From: (second user identity) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE(P-Asserted-ldentity) 
ACK 
UPDATE (From) 
200 OK UPDATE 
Apply post test routine 


Comments 


Check: Is the 'from-change' tag present in the Supported header of the initial 
INVITE request? 

Check: Is the P-Asserted-ldentity is present in a 180 Ringing or 183 Session 

Progress or in a 200 OK INVITE? 
Check: Is the 'from-change' tag present in the supported header of the 

provisional (18x) or final (200 OK) response? 
Check: Is an UPDATE request sent by the terminating user containing a From 

header field set to the value send by the terminating user? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS tip 003 


Test case group 


SIP-SIP/Service/TIP 


Reference 


4.5.2.9/[8] 


SELECTION EXPRESSION 


SE 21 AND SE 22 AND [Network B] SE 48 


Test purpose 


Second identity not provided. 

Ensure that, when the option tag "from-change" in the Supported header field 
is provided by the originating UE in the INVITE request, the terminating user 
does not receive the from-change tag in the initial INVITE, no from-change tag is 
sent in the 200 OK INVITE response, an UPDATE containing a second identity is 
sent and the From header is set to the default public user identity of the 
terminating user. 


Configuration 


Special arrangement for the terminating user does not exist 


SIP Parameter 


INVITE 

Supported: from-change 

200 OK INVITE 

P-Asserted-ldentity: 

UPDATE 

From: (default public user identity) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE(P-Asserted-ldentity) 
ACK 
UPDATE (From) 
200 OK UPDATE 
Apply post test routine 


Comments 


Check: Is the 'from-change' tag present in the Supported header of the initial 
INVITE request? 

Check: Is the P-Asserted-ldentity is present in the 200 OK INVITE? 
Check: Is the 'from-change' tag present in the supported header of the 

provisional (18x) or final (200 OK) response? 
Check: Is an UPDATE request sent by the terminating user containing a From 

header field set to the public user identity of the terminating user? 
Repeat this test in reverse direction. 
Repeat this test with all relevant end devices. 
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Test case number 


SS tip 004 


Test case group 


SIP-SIP/Service/TIP 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The Connected number presentation allowed is present in 
the encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. The Address presentation restriction indicator is set to 'allowed'. The 
screening indicator is set to Network provided or user provided, verified and 
passed. 


Configuration 




SIP Parameter 


200 OK INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 
passed 

Address presentation restriction 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
180 Ringing(ACM) 
200 OK INVITE(ANM) 
ACK 

Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 
response? 

Check: Is the Screening indicator in the encapsulated ANM set to 'Network 
provided' or 'user provided, verified and passed'? 

Check: Is the Address presentation restriction indicator in the encapsulated 
ANM set to allowed? 

Repeat this test in reverse direction. 
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Test case number 


SS tip 005 


Test case group 


SIP-SIP/Service/TIP 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The additional connected number restricted is present in the 
encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. A Generic number parameter is present the Number qualifier indicator set to 
'additional connected number' the Screening indicator is set to 'user provided, 
not verified' and the Address Presentation Restricted is set to 'allowed'. 
A Connected number parameter is present the Screening indicator is set to 
'Network provided' and the Address Presentation Restricted indicator is set to 
'allowed'. 


Configuration 


The terminating user in the PSTN/PLMN part of Network B is subscribed to the 
COLP 'no screening option' 


SIP Parameter 


200 OK INVITE 

P-Asserted-ldentity=[derived from the ISUP Connected number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

allowed 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Address Presentation Restricted 

allowed 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
180 Ringing(ACM) 
200 OK INVITE(ANM) 
ACK 

Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 
response? 

Check: Is a Generic number parameter present in the encapsulated ANM? 
Check: Is the Number Qualifier Indicator of the Generic number set to 

'additional connected number'? 
Check: Is the Screening indicator of the Generic number set to 'user provided, 

not verified'? 

Check: Is the Address presentation restriction indicator in the Generic number 

set to 'allowed'? 
Repeat this test in reverse direction. 
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7.1 .5.4 Test purposes for TIR 



Test case number 


SS tir 001 


Test case group 


SIP-SIP/Service/TIR 


Reference 


4.5.2.9/[8] I 


SELECTION EXPRESSION 


SE23 


Test purpose 


Originating user does not receive the identity of the terminating user. 

Ensure that, when the preconditions are fulfilled to prevent the presentation of 
the terminating user identity at the originating user, 

the originating UE receives, in any non-100 SIP response (e.g. 180, 183, 200), a 
Privanv hpadpr fipld i9 9Pt to "id" and no P-A^^prtpd-ldpntitv hpadpr fipld i9 
present. 


Configuration 


The terminating user subscribes to the TIR' service 


SIP Parameter 


18x/200 OK INVITE 

P-Asserted-ldentity: 
Privacy: id 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE 


CASE A 


180 Ringing 


CASE B 


183 Session Progress 


CASEC 


200 OK INVITE(P-Asserted-ldentity) 
Apply post test routine 


Comments 


Check: Is the P-Asserted-ldentity is present in the provisional (18x) or final 

(200 OK) response? 
Check: Is the Privacy header in the provisional (18x) or final (200 OK) 

response is set to 'id'? 
Repeat this test in reverse direction. 
Repeat this test with all chosen end devices. 
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Test case number 


SS tir 002 


Test case group 


SIP-SIP/Service/TIR 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The Connected number presentation allowed is present in 
the encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. The Address presentation restriction indicator is set to 'restricted'. The 
screening indicator is set to 'Network provided' or 'user provided, verified and 
passed'. 


Configuration 




SIP Parameter 


200 OK INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 
passed 

Address presentation restriction 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
180 Ringing(ACM) 
200 OK INVITE(ANM) 
ACK 

Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 
response? 

Check: Is the Screening indicator in the encapsulated ANM set to 'Network 
provided' or 'user provided, verified and passed'? 

Check: Is the Address presentation restriction indicator in the encapsulated 
ANM set to allowed? 

Repeat this test in reverse direction. 
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Test case number 


SS tir 003 


Test case group 


SIP-SIP/Service/TIR 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. The additional connected number restricted is present in the 
encapsulated 200 OK. 

Ensure that on receipt of a 200 OK INVITE to establish a confirmed dialogue an 
ANM is encapsulated if SIP-I - BICC/ISUP interworking is applicable in Network 
B. A Generic number parameter is present the Number qualifier indicator set to 
'additional connected number' the Screening indicator is set to 'user provided, 
not verified' and the Address Presentation Restricted is set to 'restricted'. 
A Connected number parameter is present the Screening indicator is set to 
'Network provided' and the Address Presentation Restricted indicator is set to 
'restricted'. 


Configuration 


The terminating user in the PSTN/PLMN part of Network B is subscribed to the 
COLP 'no screening option' 


SIP Parameter 


200 OK INVITE 

P-Asserted-ldentity=[derived from the ISUP Connected number] 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Connected number 

Screening indicator 

Network provided or user provided, verified and 

passed 
Presentation restriction 

restricted 
Address signal 
Generic number 

Number Qualifier Indicator 

Additional calling party number 
Screening indicator 

user provided, not verified 
Address Presentation Restricted 

restricted 
Address signal 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
180 Ringing(ACM) 
200 OK INVITE(ANM) 
ACK 

Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 
response? 

Check: Is a Generic number parameter present in the encapsulated ANM? 
Check: Is the Number Qualifier Indicator of the Generic number set to 

'additional connected number'? 
Check: Is the Screening indicator of the Generic number set to 'user provided, 

not verified'? 

Check: Is the Address presentation restriction indicator in the Generic number 

set to 'allowed'? 
Repeat this test in reverse direction. 
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7.1 .5.5 Communication Hold (HOLD) 



Test case number 


SS hold 001 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE 24 


Test purpose 


Hold the session the media stream was previously set to sendrecv. 

Ensure that the UE A requesting hold of the session sends an INVITE or 
UPDATE request to hold the session. Hold is done containing the SDP with the 
attribute "a=sendonly". The UE A after requesting the hold session receives 200 
OK final response containing the SDP with the attribute "a=recvonly". 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface 
A confirmed session already exists 
INVITE(sendonly) 
200 OK INVITE (recvonly) 
ACK 


SIP (Network B) 


CASE B 


UPDATE(sendonly) 
200 OK UPDATE (recvonly) 
Apply post test routine 




Comments 


Check: Is the user in network A able to set the session on hold by sending an 
INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? 

Repeat this test in reverse direction. 
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Test case number 


SS hold 


002 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Hold the session the media stream was previously set to recvonly. 

Ensure that the UE A requesting hold of the session stops sending media and 
sends an INVITE or UPDATE request to hold the session. Hold is done 
containing the SDP with the attribute "a=inactive". The UE A after requesting to 
resume the held session receives 200 OK final response containing the SDP 
with the attribute "a=inactive." 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface 
A confirmed session already exists 
INVITE (sendonly) 
200 OK INVITE (recvonly) 
ACK 
INVITE (inactive) 
200 OK INVITE (inactive) 
ACK 


SIP (Network B) 


CASE B 




INVITE (sendonly) 
200 OK INVITE (recvonly) 
ACK 

UPDATE(inactive) 
200 OK UPDATE (inactive) 




CASEC 




UPDATE (sendonly) 
200 OK UPDATE (recvonly) 
INVITE (inactive) 
200 OK INVITE (inactive) 
ACK 




CASE D 




UPDATE (sendonly) 
200 OK UPDATE (recvonly) 

UPDATE(inactive) 
200 OK UPDATE (inactive) 
Apply post test routine 




Comments 


Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 


003 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to sendonly. 

Ensure that the UE A is requested to resume the session with user B the UE-A 
starts sending media and sends an INVITE or UPDATE request to resume the 
session with the attribute "a=sendrecv in the SDP. The UE A after requesting to 
resume the held session receives 200 OK final response and optionally the 
attribute "a=sendrecv in the SDP. The a=sendrecv attribute is the default value 
therefore the attribute can be omitted. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface 
A confirmed session already exists 
INVITE (sendonly) 
200 OK INVITE (recvonly) 
ACK 

INVITE (sendrecv) 
200 OK INVITE (sendrecv) 
ACK 


SIP (Network B) 


CASE B 




INVITE (sendonly) 
200 OK INVITE (recvonly) 
ACK 

UPDATE (sendrecv) 
200 OK UPDATE (sendrecv) 




CASEC 




UPDATE (sendonly) 
200 OK UPDATE (recvonly) 

INVITE (sendrecv) 
200 OK INVITE (sendrecv) 
ACK 




CASE D 




UPDATE (sendonly) 
200 OK UPDATE (recvonly) 

UPDATE (sendrecv) 
200 OK UPDATE (sendrecv) 
Apply post test routine 




Comments 


Check: Is the user in network A able to set the session on hold by sending an 
INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? 

Check: Is the user in network A able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? The absence of the 'sendrecv' attribute is the 
default value. 

Repeat this test in reverse direction. 
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i esi case numDer 


SS hold 


004 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to inactive. 




The Session is in the "inactive" state. Ensure that the UE A is requesting to 




resume the session with user B the UE-A sends an INVITE or UPDATE to 




resume the session with the attribute "a=recvonly in the SDP. The UE A after 




requesting to resume the held session receives 200 OK final response and 




optionally the attribute "a=sendonly in the SDP 




Configuration 




SIP Parameter 




Message flow 








SIP (Network A) 




Interconnection Interface 


SIP (Network B) 




A confirmed session already exists 




CASE A 




INVITFfqpndonM 

MM V 1 1 1 IOCI IUUI Mjf 1 








PDD OK INVITF /Ypr\/nnlv\ 
















INVITFfinactive^ 

1 1 M V 1 1 1 III IHl/ll VCI 






«- 


200 OK INVITE (inactive) 








ACK 








INVITE (recvonly) 






4- 


2D0 OK INVITF CqpnrinnM 

C-\J\J Wl\ IINVI 1 1 I oCI IVJUI II y J 








ACK 




CASE B 


4- 


INVITFfsendonM 

IINVI 1 1 1 OUI IUUI My J 








PDD OK INVITF /YprvnnM 

LUU kJ\\ IInVI 1 1 ^ICLrVUIIiyy 






4- 


ACK 








UPDATE(inactive) 






«- 


200 OK UPDATE (inactive) 








INVITE (recvonly) 






«- 


200 OK INVITE (sendonly) 








ACK 




CASEC 


4- 


UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








INVITE(inactive) 








200 OK INVITE (inactive) 








ACK 








UPDATE (recvonly) 








200 OK UPDATE (sendonly) 




CASE D 




UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








UPDATE(inactive) 








200 OK UPDATE (inactive) 








UPDATE (recvonly) 








200 OK UPDATE (sendonly) 








Apply post test routine 




Comments 


Check: 


Is the user in network B able to set the session on hold by sending an 






INVITE or UPDATE request and the version parameter in the SDP 'o' 






line is incremented? 






Check: 


Is the user in network A able to set the session on hold by sending an 






INVITE or UPDATE request and the version parameter in the SDP 'o' 






line is incremented? 






Check: 


Is the user in network A able to retrieve the session by sending an 






INVITE or UPDATE request and the version parameter in the SDP 'o' 






line is incremented? 






Repeat this test in reverse direction. 
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Test case number 


SS hold 005 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE 24 


Test purpose 


Hold the session the media stream was previously set to sendrecv. 

Ensure that the UE A receives an INVITE or UPDATE request to hold the 
session and stops sending media. Hold is done containing the SDP with the 
attribute "a=sendonly". The UE A after resuming the held session sends a 200 
OK final response containing the SDP with the attribute "a=recvonly". 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 
A confirmed session already exists 

INVITE(sendonly) 
200 OK INVITE(recvonly) 
ACK 


CASE B 


4- UPDATE(sendonly) 

200 OK UPDATE (recvonly) 
Apply post test routine 


Comments 


Check: Is the user in network B able to set the session on hold by sending an 
INVITE or UPDATE request and the version parameter in the SDP 'o' 
line is incremented? 

Repeat this test in reverse direction. 
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Test case number 


SS hold 


006 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Hold the session the media stream was previously set to sendonly. 

The Session is in the "sendonly" state. Ensure that the UE A receives an INVITE 
or UPDATE request to hold the session and stops sending media. Hold is done 
containing the SDP with the attribute "a=inactive". The UE A after receiving the 
hold session sends 200 OK final response containing the SDP with the attribute 
"a=inactive". 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface 
A confirmed session already exists 
INVITE(sendonly) 
200 OK INVITE (recvonly) 
ACK 
INVITE (inactive) 
200 OK INVITE (inactive) 
ACK 


SIP (Network B) 


CASE B 




INVITE(sendonly) 
200 OK INVITE (recvonly) 
ACK 

UPDATE (inactive) 
200 OK UPDATE (inactive) 




CASEC 




UPDATE (sendonly) 
200 OK UPDATE (recvonly) 

INVITE (inactive) 
200 OK INVITE (inactive) 
ACK 




CASE D 




UPDATE (sendonly) 
200 OK UPDATE (recvonly) 

UPDATE (inactive) 
200 OK UPDATE (inactive) 
Apply post test routine 




Comments 


Check: Is the user in network A able to set the session on hold by sending an 

INVITE or UPDATE request? 
Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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Test case number 


bb nolo uu/ 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to recvonly. 

Ensure that the UE A receives an INVITE or UPDATE request requesting to 




resume the session with user B, the UE-A starts sending media. Resume is done 




containing the SDP with the attribute "a=sendrecv". The UE A after receiving the 
Resume of the session sends 200 OK final response containing the SDP with 
the attribute "a=sendrecv". The a=sendrecv attribute is the default value 
therefore the attribute can be omitted. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 
A confirmed session already exists 

INVITE (sendonly) 
200 OK INVITE(recvonly) 
ACK 
INVITE(sendrecv) 
200 OK INVITE(sendrecv) 
ACK 


CASE B 


UPDATE (sendonly) 
200 OK UPDATE (recvonly) 

UPDATE (sendrecv) 
200 OK UPDATE (sendrecv) 
Apply post test routine 


Comments 


Check: Is the user in network B able to set the session on hold by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Check: Is the user in network B able to retrieve the session by sending an 

INVITE or UPDATE request and the version parameter in the SDP 'o' 

line is incremented? 
Repeat this test in reverse direction. 
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i esi case numDer 


SS hold 


008 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session the media stream was previously set to inactive. 




The Session is in the "inactive" state. Ensure that the UE A receives an INVITE 




or UPDATE request requesting to resume the session with user B, the UE-A 




starts sending media. Resume is done containing the SDP with the attribute 




"a=recvonly". The UE A after receiving the Resume of the session sends 200 OK 




final response containing the SDP with the attribute "a=sendonly". The 




a=sendrecv attribute is the default value therefore the attribute can be omitted. 


Configuration 




SIP Parameter 




Message flow 








SIP (Network A) 




Interconnection Interface 


SIP (Network B) 




A confirmed session already exists 




CASE A 




iiNivi i c ^bciiuuiiiyj 








200 OK INVITE (recvonM 

L—KJKJ 1 \ II M v 1 1 1 M UljVUI 1 1 y / 








ACK 








INVITE (inactive) 








900 DK IMX/ITF (\nar\\\f(*\ 

tl/U \Ji\ IINIVI 1 C y\l IdULI vk5) 








ACK 








INVITE (recvonM 

iiNvi i i iicwvuiiiyi 








200 OK INVITF CqpnrinnM 

L.uu iinvi i i i oci iuui iiy i 






4- 


ACK 




CASE B 




INVITF /^pnrlnnlvl 
MM VI 1 i ^odiuuinyy 






4- 


200 OK INVITE /YprvnnM 

C-\J\J V^IA IINVI 1 1 ^ICvyVUIIiyy 








ACK 






«- 


UPDATE (inactive) 








200 OK UPDATE (inactive) 






«- 


UPDATE (recvonly) 








200 OK UPDATE (sendonly) 




CASEC 




UPDATE (sendonly) 






4- 


200 OK UPDATE (recvonly) 








INVITE (inactive) 








200 OK INVITE (inactive) 








ACK 








INVITE (recvonly) 








200 OK INVITE (sendonly) 








ACK 




CASE D 




UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








UPDATE (inactive) 








200 OK UPDATE (inactive) 






4- 


UPDATE (recvonly) 








200 OK UPDATE (sendonly) 








Apply post test routine 




Comments 


Check: 


Is the user in network B able to set the session on hold by sending an 






INVITE or UPDATE request and the version parameter in the SDP 'o' 






line is incremented? 






Check: 


Is the user in network A able to set the session on hold by sending an 






INVITE or UPDATE request and the version parameter in the SDP 'o' 






line is incremented? 






Check: 


Is the user in network B able to retrieve the session by sending an 






INVITE or UPDATE request and the version parameter in the SDP 'o' 






line is incremented? 






Repeat this test in reverse direction. 
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Test case number 


SS hold 


009 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session on both sides the media stream was previously set to 




inactive. 








The Session is in the "inactive" state. Ensure that the UE A is requesting to 




resume the session with user B, the UE-A starts sending media and sends an 




INVITE or UPDATE request to resume the session with the attribute 




"a=sendonly in the SDP. The UE A after requests to resume the session 




receives 200 OK final response containing the SDP with the attribute 




"a=recvonly. The UE B after requests to resume the session receives 200 OK 




final response containing the SDP with the attribute "a=sendrecv". The 




a=sendrecv attribute is the default value therefore the attribute can be omitted. 


Message flow 








SIP (Network A) 




Interconnection Interface 


SIP (Network B) 


A confirmed session already exists 




CASE A 




INVITE(sendonly) 






200 OK INVITE (recvonly) 






ACK 






INVITE(inactive) 






200 OK INVITE (inactive) 






ACK 






INVITE(sendonly) 






200 OK INVITE (recvonly) 






ACK 






INVITE(sendrecv) 






200 OK INVITE (sendrecv) 






ACK 




CASE B 




INVITE(sendonly) 






200 OK INVITE (recvonly) 






ACK 






UPDATE (inactive) 






200 OK UPDATE (inactive) 






INVITE(sendonly) 






200 OK INVITE (recvonly) 






ACK 






UPDATE (sendrecv) 






200 OK UPDATE (sendrecv) 




CASEC 




UPDATE (sendonly) 






200 OK UPDATE (recvonly) 






INVITE(inactive) 






200 OK INVITE (inactive) 






ACK 






UPDATE (sendonly) 






200 OK UPDATE (recvonly) 






ACK 






INVITE(sendrecv) 






200 OK INVITE (sendrecv) 






ACK 




CASE D 




UPDATE (sendonly) 






200 OK UPDATE (recvonly) 






UPDATE (inactive) 






200 OK UPDATE (inactive) 






UPDATE (sendonly) 






200 OK UPDATE (recvonly) 






UPDATE (sendrecv) 






200 OK UPDATE (sendrecv) 






Apply post test routine 
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Comments 


Check: 


Is the user in network A able to set the session on hold by sending 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? 


an 
'o' 




Check: 


Is the user in network B able to set the session on hold by sending 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? 


an 

'0' 




Check: 


Is the user in network A able to retrieve the session by sending an 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? 


'0' 




Check: 


Is the user in network B able to retrieve the session by sending an 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? The absence of the 'sendrecv' attribute is the 
default value. 


'o' 




Repeat this test in reverse direction. 
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Test case number 


SS hold 


010 




Test case group 


SIP-SIP/Service/HOLD 


Reference 


4.5.2.1/[17] 


SELECTION EXPRESSION 


SE24 


Test purpose 


Resume the session on both sides the media stream was previously set to 




inactive. 








The Session is in the "inactive" state. Ensure that the UE A receives an INVITE 




or UPDATE to resume the session with user B, the UE-A starts sending media. 




Resume is done containing the SDP with the attribute "a=recvonly". The UE A 




after receiving the Resume of the session sends 200 OK final response 




containing the SDP with the attribute "a=sendonly". The UE A after requests to 




resume the session receives 200 OK final response containing the SDP with the 




attribute "a=sendrecv. The UE B after receiving the Resume of the session 




sends 200 OK final response containing the SDP with the attribute "a=sendrecv". 




The a=sendrecv attribute is the default value therefore the attribute can be 




omitted. 






Configuration 




SIP Parameter 




Message flow 








SIP (Network A) 




Interconnection Interface 


SIP (Network B) 




A confirmed session already exists 




CASE A 




INVITEfqpndonM 

MM V 1 1 1 1 OCI IUUI My y 








200 OK INVITF /YprvnnM 






4- 


ACK 








INVITEfinartivp^ 

II N V 1 1 1 (II IGOU VC 1 






«- 


200 OK INVITE (inactive) 








ACK 






4- 


INVITEfsendonM 

MM VI 1 1 ^OCI IUUI II y J 








200 OK INVITE (rprvnnM 






4- 


ACK 








INVITFCspndrpcv'l 

MM VI 1 LI9CIIUICV/VI 






4- 


200 OK INVITE tepndrpeV) 

L—\J\J V-X 1 \ MM V 1 1 1 \ OCI IUI ULiV 1 








ACK 




CASE B 


4- 


INVITEfqpndnnM 

mmvi i i ^odivjuiiiyy 








200 OK INVITE (recvonlv) 








ACK 








UPDATE (inactive) 








200 OK UPDATE (inactive) 








INVITE(sendonly) 








200 OK INVITE (recvonly) 








ACK 








UPDATE (sendrecv) 








200 OK UPDATE (sendrecv) 




CASEC 




UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








INVITE(inactive) 








200 OK INVITE (inactive) 








ACK 








UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








INVITE(sendrecv) 








200 OK INVITE (sendrecv) 








ACK 




CASE D 




UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








UPDATE (inactive) 








200 OK UPDATE (inactive) 








UPDATE (sendonly) 








200 OK UPDATE (recvonly) 








UPDATE (sendrecv) 








200 OK UPDATE (sendrecv) 








Apply post test routine 
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Comments 


Check: 


Is the user in network B able to set the session on hold by sending 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? 


an 
'o' 




Check: 


Is the user in network A able to set the session on hold by sending 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? 


an 

'0' 




Check: 


Is the user in network B able to retrieve the session by sending an 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? 


'o' 




Check: 


Is the user in network A able to retrieve the session by sending an 
INVITE or UPDATE request and the version parameter in the SDP 
line is incremented? The absence of the 'sendrecv' attribute is the 
default value. 


'o' 




Repeat this test in reverse direction. 





Test case number 


SS hold 011 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the calling user. 

Ensure that when an INVITE request updates a confirmed session a CPG is 
encapsulated if ISUP - SIP-I interworking is applicable in Network A. The 
Generic Notification Indicator parameter is present set to 'hold'. The 'a' attribute 
is set to 'sendonly' present in the SDP. 

In the 200 OK INVITE the 'a' attribute is set to 'recvonly' present in the SDP. 


Configuration 




SIP Parameter 


NVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

a=sendonly 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic notification 
remote hold 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly, CPG hold) 

200 OK INVITE (recvonly) 
ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network A places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold ? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 



ETSI 



86 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS hold 012 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the called user. 

Ensure that when an INVITE request updates a confirmed session a CPG is 
encapsulated if SIP-I - ISUP interworking is applicable in Network B. The 
Generic Notification Indicator parameter is present set to 'hold'. The 'a' attribute 
is set to 'sendonly' present in the SDP. 

In the 200 OK INVITE the 'a' attribute is set to 'recvonly' present in the SDP. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

a=sendonly 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic notification 
remote hold 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
CASE A INVITE(sendonly, CPG hold) 

200 OK INVITE (recvonly) 
ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network B places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold ? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 013 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the originating user, Hold by the 
terminating user. Retrieve requested by the originating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Originating user in Network A places the session on hold. 

• Terminating user in Network B places the session on hold. 

• Originating user in Network A retrieves the session. 

• Terminating user in Network B retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 




-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 
or 

remote retrieval 
-[any boundary name]- 




Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 
A confirmed session already exists 

INVITE(sendonly, CPG hold) 
200 OK INVITE (recvonly) 
ACK 

INVITE(inactive) 
200 OK INVITE (inactive) 
ACK 

INVITE(sendonly, CPG retrieval) 
200 OK INVITE (recvonly) 
ACK 

INVITE(sendrecv) 
200 OK INVITE (sendrecv) 
ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network A places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold ? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B places the session on hold 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval ? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 014 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the originating user, Hold by the 
terminating user. Retrieve requested by the terminating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Originating user in Network A places the session on hold. 

• Terminating user in Network B places the session on hold. 

• Terminating user in Network B retrieves the session. 

• Originating user in Network A retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 




-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 
or 

remote retrieval 
-[any boundary name]- 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
A confirmed session already exists 

INVITE(sendonly, CPG hold) 
200 OK INVITE (recvonly) 
ACK 

INVITE(inactive) 
200 OK INVITE (inactive) 
ACK 

INVITE(recvonly) 
200 OK INVITE (sendonly) 
ACK 

INVITE(sendrecv, CPG retrieval) 
200 OK INVITE (sendrecv) 
ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in the PSTN/PLMN part of Network A places the session on hold. 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold ? 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B places the session on hold 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'recvonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval ? 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 015 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the terminating user, Hold by the 
originating user. Retrieve requested by the originating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Terminating user in Network B places the session on hold. 

• Originating user in Network A places the session on hold. 

• Originating user in Network A retrieves the session. 

• Terminating user in Network B retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 




-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 
or 

remote retrieval 
-[any boundary name]- 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
A confirmed session already exists 

INVITE(sendonly) 
200 OK INVITE (recvonly) 
ACK 

INVITE(inactive, CPG hold) 
200 OK INVITE (inactive) 
ACK 

INVITE(recvonly, CPG retrieval) 
200 OK INVITE (sendonly) 
ACK 

INVITE(sendrecv) 
200 OK INVITE (sendrecv) 
ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in Network B places the session on hold. 

Check: Is the 'a' attribute in the SDP set to 'sendonly'? 

Check: Is the Version parameter in the SDP incremented? 

The user in Network A places the session on hold 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold ? 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval ? 
Check: Is the 'a' attribute in the SDP set to 'recvonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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Test case number 


SS hold 016 


Test case group 


SIP-SIP/Service/HOLD 


Reference 


B.10/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 54 


Test purpose 


SIP-I support. Hold requested by the terminating user, Hold by the 
originating user. Retrieve requested by the terminating user. 

Ensure the hold and retrieve procedure when ISUP - SIP-I interworking applies 
in the Network A: 

• Terminating user in Network B places the session on hold. 

• Originating user in Network A places the session on hold. 

• Terminating user in Network B retrieves the session. 

• Originating user in Network A retrieves the session. 

Verify the Generic notification parameter in the encapsulated CPG present in the 
INVITE request from the Network A. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: multipart/mixed;boundary=[any boundary name] 




-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic notification 
remote hold 
or 

remote retrieval 
-[any boundary name]- 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
A confirmed session already exists 

INVITE(sendonly) 
200 OK INVITE (recvonly) 
ACK 

INVITE(inactive, CPG hold) 
200 OK INVITE (inactive) 
ACK 

INVITE(sendonly) 
200 OK INVITE (recvonly) 
ACK 

INVITE(sendrecv, CPG retrieval) 
200 OK INVITE (sendrecv) 
ACK 

Apply post test routine 


Comments 


Establish a session from Network A to Network B 

The user in Network B places the session on hold. 

Check: Is the 'a' attribute in the SDP set to 'sendonly'? 

Check: Is the Version parameter in the SDP incremented? 

The user in Network A places the session on hold 

Check: Is a CPG encapsulated in the INVITE request? 

Check: Is a Generic notification parameter present the Notification indicator 

set to remote hold ? 
Check: Is the 'a' attribute in the SDP set to 'inactive'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network B retrieves the session 
Check: Is the 'a' attribute in the SDP set to 'sendonly'? 
Check: Is the Version parameter in the SDP incremented? 
The user in Network A retrieves the session 
Check: Is a CPG encapsulated in the INVITE request? 
Check: Is a Generic notification parameter present the Notification indicator 

set to remote retrieval ? 
Check: Is the 'a' attribute in the SDP set to 'sendrecv'? 
Check: Is the Version parameter in the SDP incremented? 
Repeat this test in reverse direction. 
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7.1.5.6 Communication Diversion (CDIV) 



7.1.5.6.1 Communication Forwarding Unconditional (CFU) 



Test case number 


SS cfu 001 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 


Test purpose 


Communication forwarding unconditional, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFU. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C. In the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
^ l oU Hinging(uaii-iu b-Aj 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID B-C) 
200 OK INVITE(Call-ID B-A) 
ACK(Call-ID A-B) 
Communication 
Apply post test routine 


Comments 


Check: CDIV unconditional is successful. 
Check: In the active call state, ensure the property of speech. 
Check: Is the P-Asserted-ldentity present set to the identity of the originating 
user? 

Repeat this test in reverse direction. 



Test case number 


SS_cfu_002 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 25 AND SE 30 


Test purpose 


Communication forwarding unconditional, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFU, subscription option: Originating user receives notification that 
his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, the originating user is not notified. 


Configuration 


Subscription options: 




Originating user receives notification that his communication has been diverted = 




No 


SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 

CFU is performed 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 003 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 AND SE 30 


Test purpose 


Communication forwarding unconditional, originating user is notified. URI 
of the diverted-to user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" =No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and not informed of the diverted-to number 
and served user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


181 Being Forwarded 

History-Info: ^^^^^^^^ 

<sip:userB@networkB?Privacy=history>;index=1 , 

<sip: userC@networkA;cause=302?Privacy=history>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry is set to '302' 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfu 004 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 AND SE 30 


Test purpose 


Communication forwarding unconditional, originating user is notified. URI 
from the diverted-to user received. 

The user A and user C are in network 1 . The user B is in network N2 and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and "Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = Yes. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 


SIP Parameter 


181 Being Forwarded 
History-Info: 

<sip:userB@networkB>;index= 1 , 

<sip: userC@networkA;cause=302>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at the interconnection interface 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry is set to '302'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 005 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 AND SE 30 


Test purpose 


Communication forwarding unconditional, diverted-to user does not 
receive the URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Served user allows the presentation of his/her URI to the 
diverted-to user"= No. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: 

Request line contains ';cause=302' 

History-Info header: 

<sip:userB@networkB?Privacy=history>;index=1 , 
<sip: userC@networkA;cause=302>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '302'? 

Check: Is the cause parameter in the last entry is set to '302'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfu 006 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 AND SE 30 


Test purpose 


Communication forwarding unconditional, diverted-to user receives the 
URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU "Served user allows the presentation of his/her URI to 
diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user C is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=302' 
History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=302>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '302'? 

Check: Is the cause parameter in the last entry is set to '302'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfu 007 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 AND SE 30 


Test purpose 


Communication forwarding unconditional, full notification. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = Yes, and "Served user 
allows the presentation of his/her URI to diverted-to user" = Yes. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number and 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 


• Originating user receives notification that his communication has been 




diverted = Yes ^^^^^^^^^^^^^ 
• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 




• Served user allows the presentation of his/her URI to diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=302' 
History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=302>;index=1 .1 

181 Being Forwarded 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .1 




200 OK INVITE 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID C-B) 
200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) * 
Communication 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '302'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 008 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 25 


Test purpose 


Communication forwarding unconditional, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C user C is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 

INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) * 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 




Test case number 


SS cfu 009 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE25 


Test purpose 


Communication forwarding unconditional, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 

C and user C is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 

INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-ID A-B) 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 010 


Test case group 


SIP-SIP/Service/CFU 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 25 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication forwarding unconditional, interaction with a not trusted 
network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and not informed of the diverted-to number 
and user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: no History-Info header 

181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C) 
4- 181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the 

interconnection interface. 
Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 011 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, without diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if 
SIP-I - ISUP/BICC interworking is applicable in Network B. 


Configuration 


Subscription options: ^^^^^^^^^^^^^^^^^^^^^^ 
• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 
unconditional 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 
allowed'? 

Check: Is the Redirecting reason set to 'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 012 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, without diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if 
SIP-I - ISUP/BICC interworking is applicable in Network B. 


Configuration 


Subscription options: ^^^^^^^^^^^^^^^^^^^^^^ 
• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 
unconditional 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 013 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, with diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 
Redirecting reason 
unconditional 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFU is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation 

allowed with redirection number'? 
Check Is the Redirecting reason set to 'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 014 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFU performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
CFU is performed 

INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 
Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 015 


Test case group 


SIP-SIP/Service/CFU 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFU performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Diverted-to user is not subscribed to the 
COLR service. 

Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, if a Redirection number restriction parameter is present it is set to 
'Presentation allowed' in the encapsulated ANM contained in the 200 OK INVITE 
if ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 

Redirection number restriction not present 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
CFU is performed 
INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 



ETSI 



104 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS cfu 016 


Test case group 


SIP-SIP/Service/CFU 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user C is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated 1AM contained in the 
Redirecting number 'presentation allowed' and Redirection information if 
ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: ^^^^^^^^^^^^^ ^^^^^^^^^ 




• Served user releases his/her number to diverted-to user = Release diverting 




number information 


SIP Parameter 


Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

1AM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

unconditional 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
CFU is performed 
^H(Call-ID B-C, 1AM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an 1AM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'unconditional'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfu 017 


Test case group 


SIP-SIP/Service/CFU 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFU performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFU, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded unconditional to user 
C, user C is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated IAM contained in the 
Redirecting number 'presentation restricted' and Redirection information if 
ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

unconditional 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
CFU is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'unconditional'? 
Repeat this test in reverse direction. 
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7.1 .5.6.2 Communication Forwarding Busy (CFB) 



Test case number 


SS cfb 001 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 26 


Test purpose 


Communication forwarding busy, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFB. 

Ensure that when user A calls user B, the call is forwarded busy to user C. In the 
active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID B-C) 
200 OK INVITE(Call-ID B-A) 
ACK(Call-ID A-B) 
Communication 
Apply post test routine 


Comments 


Check: CDIV busy is successful. 

Check: In the active call state, ensure the property of speech. 
Check: Is the P-Asserted-ldentity present set to the identity of the originating 
user? 

Repeat this test in reverse direction. 



Test case number 


SS cfb 002 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 26 AND SE 30 


Test purpose 


Communication forwarding busy, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFB, subscription option: Originating user receives notification that 
his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded busy to user C, 
originating user is not notified. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 

CFB is performed 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 003 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 AND SE 30 


Test purpose 


Communication forwarding busy, originating user is notified. URI from the 
served user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification" = No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B, the call is forwarded busy to user C, user 
A is notified of call diversion and not informed of the diverted-to number and 
served user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^ ^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


181 Being Forwarded ^^^^^^^ 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=486>;index=1 , 
<sip: userC@networkA;cause=486 ?Pr/Vacy=/7/sfory> ;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry set to '486'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfb 004 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 AND SE 30 


Test purpose 


Communication forwarding busy, originating user is notified. URI from the 
diverted-to user received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification" =Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user C, user 
A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

✓"N ■ ■ ■ ■ ■ i ' f ' ■'■III' ■ ■ ■ 1 1 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification =Yes 


SIP Parameter 


181 Being Forwarded 

<sip:userB@networkB?Reason=S\P; cause=486>;//7dex= 1, 
<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry set to '486'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 005 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 AND SE 30 


Test purpose 


Communication forwarding busy, diverted-to user does not receive the URI 
of the served user. 

The user A and user C are in network C. The user B is in network B and is 
provided with CFB Served user allows the presentation of his/her URI to the 
diverted-to user" = No. 

Ensure that when user A calls user B, the call is forwarded busy to user C, user 
C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: 

Request line contains ';cause=486' 
History-Info header: 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=486>;index=1 , 

<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '486'? 

Check: Is the cause parameter in the last entry set to '486'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfb 006 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 AND SE 30 


Test purpose 


Communication forwarding busy, diverted-to user receives the URI of the 
served user. 

The user A and user C are in network C. The user B is in network B and is 
provided with CFB Served user allows the presentation of his/her URI to the 
diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user C, user 
C is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=486' 

History-Info header: 

<sip:userB@networkB?Reason=SIP;cause=486>;index=1 , 
<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '486'? 

Check: Is the cause parameter in the last entry set to '486'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfb 007 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 AND SE 30 


Test purpose 


Communication forwarding busy, full notification. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification'^ Yes, "diverting number is 
released to the diverted-to user" =Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user C, user 
A is notified of call diversion and informed of the diverted-to number and user C 
is informed of the forwarding number. 


Configuration 


Subscription options: 


• Originating user receives notification that his communication has been 




diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes, 

• diverting number is released to the diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=486' 

History-Info header: 

<sip:userB@networkB&Reason=SIP;cause=486>;index=1 , 
<sip: userC@networkA;cause=486>;index=1 .1 




181 Being Forwarded 

History-Info header: 




<sip:userB@networkB&Reason=SIP;cause=486>;index=1 , 
<sip: userC@networkA;cause=486>;index=1 .1 




200 OK INVITE 

History-Info header: 

<sip:userB@networkB&Reason=SIP;cause=486>;index=1 , 
<sip: userC@networkA;cause=486>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID C-B) 
200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) * 
Communication 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '486'? 
Check: Is the cause parameter in the last entry set to '486'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 008 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 26 


Test purpose 


Communication forwarding busy, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB. 

Ensure that when user A calls user B, the call is forwarded busy to user C and 
user C is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 

4- INVITE(Call-ID B-C) 

486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) * 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 



Test case number 


SS cfb 009 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE26 


Test purpose 


Communication forwarding busy, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB. 

Ensure that when user A calls user B, the call is forwarded busy to user C and 
user C is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) * 
CFB is performed 

INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-ID A-B) 


Comments 


Check: A 181 Being Forwarded is received at network 1 originating access. 
Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 010 


Test case group 


SIP-SIP/Service/CFB 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 26 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication forwarding busy, interaction with a not trusted network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFB Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded busy to user C, user 
A is notified of call diversion and not informed of the diverted-to number and user 
C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: no History-Info header 

181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C) 
4- 181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 
interface. 

Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 011 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, without diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user A is not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 
User Busy 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 
allowed'? 

Check: Is the Redirecting reason set to User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 012 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, without diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 
User Busy 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 013 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Calling user receives notification that his 
call has been diverted (forwarded or deflected) = yes, with diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number (Diverted-to user) 

Address signal 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 
Redirecting reason 
User Busy 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFB is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 014 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFB performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
CFB is performed 

INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 
Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 015 


Test case group 


SIP-SIP/Service/CFB 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFB performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Diverted-to user is not subscribed to the 
COLR service. 

Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, if a Redirection number restriction parameter is present it is set to 
'Presentation allowed' in the encapsulated ANM contained in the 200 OK INVITE 
if ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 

Redirection number restriction not present 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
CFB is performed 
INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 016 


Test case group 


SIP-SIP/Service/CFB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user C is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated 1AM contained in the 
Redirecting number 'presentation allowed' and Redirection information if 
ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: ^^^^^^^^^^^^^ ^^^^^^^^^ 




• Served user releases his/her number to diverted-to user = Release diverting 




number information 


SIP Parameter 


Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

1AM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

User Busy 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
CFB is performed 
^H(Call-ID B-C, 1AM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an 1AM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'User Busy'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfb 017 


Test case group 


SIP-SIP/Service/CFB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFB performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFB, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded on busy user to user 
C, user C is notified of call diversion and informed of the diverting number. 
The notification information is present in the encapsulated IAM contained in the 
Redirecting number 'presentation restricted' and Redirection information if 
ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

User Busy 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
CFB is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'User Busy'? 
Repeat this test in reverse direction. 
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7.1 .5.6.3 Communication Forwarding No Reply (CFNR) 



Test case number 


SS cfnr 001 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 27 


Test purpose 


Communication forwarding no reply, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNR. 

Ensure that when user A calls user B, the call is forwarded no reply to user C. In 
the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID B-C) 
200 OK INVITE(Call-ID B-A) 
ACK(Call-ID A-B) 
Communication 
Apply post test routine 


Comments 


Check: CDIV no reply is successful. 

Check: In the active call state, ensure the property of speech. 
Check: Is the P-Asserted-ldentity present set to the identity of the originating 
user? 

Repeat this test in reverse direction. 




Test case number 


SS cfnr 002 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 AND SE 30 


Test purpose 


Communication forwarding no reply, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNR, subscription option: Originating user receives notification 
that his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
originating user is not notified. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) * 
180 Ringing(Call-ID B-A) 

CFB is performed 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 003 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 AND SE 30 


Test purpose 


Communication forwarding no reply, originating user is notified. URI from 
the served user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes ("Served user allows the presentation of 
forwarded to URI to originating user in diversion notification" = No and. "Served 
user allows the presentation of his/her URI to originating user in diversion 
notification" = No. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user A is notified of call diversion and not informed of the diverted-to number and 
served user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


181 Being Forwarded ^^^^^^^^ 

<sip:userB@networkB?Privacy=history>;index=1 , 

<sip: userC@networkA;cause=408?Privacy=history>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry is set to '408'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnr 004 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 AND SE 30 


Test purpose 


Communication forwarding no reply, originating user is notified. URI from 
the diverted-to user received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes and "Served user allows the 
presentation of forwarded to URI to originating user in diversion notification" 
=Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification =Yes 


SIP Parameter 


181 Being Forwarded 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at the interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry is set to '408'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 005 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 AND SE 30 


Test purpose 


Communication forwarding no reply, diverted-to user does not receive the 
URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 

1 I I ■ ■ i ii /— \ I II ■ i ■ ■ ■ r i ■ /i i i i— \ i iii i 1 ■ i 

provided with Served user allows the presentation of his/her URI to the diverted- 
to user" = No. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE 

Request line contains ';cause=408' 

History-Info header: 

<sip:userB@networkB?Privacy=history>;index=1 , 
<sip: userC@network1 ;cause=408>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '408'? 

Check: Is the cause parameter in the last entry is set to '408'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 




Test case number 


SS cfnr 006 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 AND SE 30 


Test purpose 


Communication forwarding no reply, diverted-to user receives the URI of 
the diverted-to user. 

The user A and user C are in network A. The user B is in network B and is 
provided with "Served user allows the presentation of his/her URI to the diverted- 
to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user C is informed of the forwarding number. 


Configuration 


Subscription options: ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
• Served user allows the presentation of his/her URI to the diverted-to user = 
Yes 


SIP Parameter 


INVITE 

Request line contains ';cause=408' 
History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@network1 ;cause=408>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 
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Test case number 


SS cfnr 007 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 AND SE 30 


Test purpose 


Communication forwarding no reply, full notification. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes, ("Served user allows the presentation 
of forwarded to URI to originating user in diversion notification" = Yes, "diverting 
number is released to the diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user A is notified of call diversion and informed of the diverted-to number and 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 


• Originating user receives notification that his communication has been 




diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 

• diverting number is released to the diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=408' 

History-Info header: 

<sip:userB@networkB&Reason=SIP;cause=408>;index=1 , 
<sip: userC@networkA;cause=486>;index=1 .1 

181 Being Forwarded 

History-Info header: 

<sip:userB@network>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .1 




200 OK INVITE 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=408>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID C-B) 
200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '408'? 
Check: Is the cause parameter in the last entry is set to '408'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 008 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 27 


Test purpose 


Communication forwarding no reply, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR. 

Ensure that when user A calls user B, the call is forwarded no reply to user C 
and user C is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 

INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-ID A-B) 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 




Test case number 


SS cfnr 009 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE27 


Test purpose 


Communication forwarding no reply, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR. 

Ensure that when user A calls user B, the call is forwarded no reply to user C 
and user C is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) * 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 010 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 27 AND SE 30 AND [Network A] is SE 9 


Test purpose 


Communication forwarding no reply, interaction with a not trusted 
network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNR Originating user receives notification that his 
communication has been diverted = Yes ("Served user allows the presentation of 
forwarded to URI to originating user in diversion notification"=Yes, "diverting 
number is released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded no reply to user C, 
user A is notified of call diversion and not informed of the diverted-to number and 
user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: no History-Info header 

181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing(Call-ID B-A) 
CFB is performed 
INVITE(Call-ID B-C) 
4- 181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 
interface. 

Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 011 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
user A is not notified about call diversion. 

The notification information is present in the encapsulated CPG contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Event indicator 

Alerting or Progress 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 
presentation not allowed 

Redirecting reason 
No reply 
Generic notification 

call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
1 80 Ringing (Call-ID B-A, ACM) 
CFNR is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 
Check: Is an CPG encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 
allowed'? 

Check: Is the Redirecting reason set to 'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 012 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated CPG contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Event indicator 

Alerting or Progress 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 

Redirecting reason 
No reply 
Generic notification 

call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
1 80 Ringing (Call-ID B-A, ACM) 
CFNR is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an CPG encapsulated in the 1 83? 
Check: is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 013 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, with diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
user A is notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated CPG contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Event indicator 

Alerting or Progress 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 

Redirecting reason 
No reply 
Generic notification 

call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
1 80 Ringing (Call-ID B-A, ACM) 
CFNR is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an CPG encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 014 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNR performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
1 80 Ringing (Call-ID B-A, ACM) 
CFNR is performed 
INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 
Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 015 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNR performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNR, Diverted-to user is not subscribed to 
the COLR service. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 
if a Redirection number restriction parameter is present it is set to 'Presentation 
allowed' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 

Redirection number restriction not present 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
180 Ringing (Call-ID B-A) 
CFNR is performed 
INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 016 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNR, Served user releases his/her number 

to diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 

user C is notified of call diversion and informed of the diverting number. 

The notification information is present in the encapsulated 1AM contained in the 

Redirecting number 'presentation allowed' and Redirection information if 

ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: ^^^^^^^^^^^^^ ^^^^^^^^^ 




• Served user releases his/her number to diverted-to user = Release diverting 




number information 


SIP Parameter 


Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

1AM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

No reply 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A, ACM) 
CFNR is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'No reply'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnr 017 


Test case group 


SIP-SIP/Service/CFNR 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNR performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CFNR, Served user releases his/her number 

to diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is forwarded on no reply to user C, 

user C is notified of call diversion and informed of the diverting number. 

The notification information is present in the encapsulated IAM contained in the 

Redirecting number 'presentation restricted' and Redirection information if 

ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

No reply 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A, ACM) 
CFNR is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'No reply'? 
Repeat this test in reverse direction. 
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7.1 .5.6.4 Communication Forwarding Not Logged in (CFNL) 



Test case number 


SS cfnl 001 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 28 


Test purpose 


Communication forwarding not logged in, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNL. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C. In the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID B-C) 
200 OK INVITE(Call-ID B-A) 
ACK(Call-ID A-B) 
Communication 
Apply post test routine 


Comments 


Check: The CDIV not logged in is successful. 
Check: In the active call state, ensure the property of speech. 
Check: Is the P-Asserted-ldentity present set to the identity of the originating 
user? 

Repeat this test in reverse direction. 




Test case number 


SS cfnl 002 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE28 AND SE 30 


Test purpose 


Communication forwarding not logged in, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFNL, subscription option: Originating user receives notification 
that his communication has been diverted = No. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, originating user is not notified. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) * 

CFNL is performed 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 003 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE28 AND SE 30 


Test purpose 


Communication forwarding not logged in, originating user is notified. URI 
of the diverted-to user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, user A is notified of call diversion and not informed of the diverted-to number 
and the served user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


181 Being Forwarded ^^^^^ 

<sip:userB@networkB ?Privacy=history>;index= 1 , 

<sip: userC@networkA;cause=404 ?Privacy=history>;index= 1 . 1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at 

theinterconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: is the cause parameter in the last entry is set to '404'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnl 004 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE28 AND SE 30 


Test purpose 


Communication forwarding not logged in, originating user is notified. URI 
from the diverted-to user received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = Yes. 
Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, user A is notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

✓"N ■ ■ ■ ■ ■ i ' f ' ■'■III' ■ ■ ■ 1 1 

• Originating user receives notification that his communication has been 
^^^T=Yes 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 


SIP Parameter 


181 Being Forwarded 

<sip:userB@networkB>;index= 1 , 

<sip: userC@networkA;cause=404>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

served user and the URI of the diverted-to user. 
Check: Is the cause parameter in the last entry is set to '404'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 005 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE28 AND SE 30 


Test purpose 


Communication forwarding not logged in, diverted-to user does not 
receive the URI of the diverted-to user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL "Served user allows the presentation of his/her URI to 
diverted-to user" = No. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = No 


SIP Parameter 


INVITE 

Request line contains ';cause=404' 
History-Info header: ^^^^^^^^ 

<sip:userB@networkB?Privacy=history>;index=1 , 
<sip: userC@network1 ;cause=404>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface and a Privacy 
header is escaped set to 'history'. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '404'? 

Check: Is the cause parameter in the last entry is set to '404'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnl 006 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE28 AND SE 30 


Test purpose 


Communication forwarding not logged in, diverted-to user receives the URI 
of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL "Served user allows the presentation of his/her URI to 
diverted-to user" = Yes. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, user C is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = Yes 


SIP Parameter 


INVITE 

Request line contains ';cause=404' 
History-Info header: 

<sip:userB@networkB>;index= 1 , 

<sip: userC@networkA;cause=404>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '404'? 

Check: Is the cause parameter in the last entry is set to '404'? 

NOTE: The history entries can be accumulated in "one" History-Info header or 
each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cfnl 007 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE28 AND SE 30 


Test purpose 


Communication forwarding not logged in, full notification. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes, ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification" =Yes, "diverting number is 
released to the diverted-to user" =Yes. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, user A is notified of call diversion and informed of the diverted-to number and 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 


• Originating user receives notification that his communication has been 




diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = Yes 

• diverting number is released to the diverted-to user = Yes 


SIP Parameter 


INVITE: 

Request line contains ';cause=404' 

History-Info header: 

<sip:userB@networkB&Reason=SIP;cause=404>;index=1 , 
<sip: userC@networkA;cause=404>;index=1 .1 

181 Being Forwarded 

History-Info header: 

<sip:userB@network>;index=1 , 

<sip: userC@networkA;cause=404>;index=1 .1 




200 OK INVITE 

History-Info header: 

<sip:userB@networkB>;index=1 , 

<sip: userC@networkA;cause=404>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID C-B) 
200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) * 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE at the interconnection 

interface sent to user C containing the URI identifying the served user. 
Check: A History-Info header is received in the 181 Being Forwarded at the 

interconnection interface sent to user A containing the URI identifying 

the diverted-to user. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '404'? 
Check: Is the cause parameter in the last entry is set to '404'? 
NOTE: The history entries can be accumulated in "one" History-Info header or 

each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 008 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 28 


Test purpose 


Communication forwarding not logged in, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C and user C is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 

486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-IDA-B) * 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 




Test case number 


SS_cfnl_009 


Test case group 


4.5.2.6/[9] 


Reference 


ES 183 004 


SELECTION EXPRESSION 


SE28 


Test purpose 


Communication forwarding not logged in, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C and user C is busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) * 
CFNL is performed 

486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID A-B) 

ACK(Call-ID A-B) 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 010 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 28 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication forwarding not logged in, interaction with a not trusted 
network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFNL Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, user A is notified of call diversion and not informed of the diverted-to number 
and user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of forwarded to URI to originating user 
in diversion notification = No ^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 

• Served user allows the presentation of his/her URI to the diverted-to user = 
No 


SIP Parameter 


INVITE: no History-Info header 

181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C) 
4- 181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 
interface. 

Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface (if sent). 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 011 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 
not reachable to user C, user A is not notified about call diversion. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = no 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 

Mobile subscriber not reachable 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 
allowed'? 

Check: Is the Redirecting reason set to 'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 012 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 
not reachable to user C, user A is notified of call diversion and informed of the 
diverted-to number. 

The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 

Mobile subscriber not reachable 
Generic notification 
call is diverting 

-[any boundary narne]-- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 013 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Calling user receives notification that 
his call has been diverted (forwarded or deflected) = yes, with diverted-to user 
number. 

Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 
not reachable to user C, user A is notified of call diversion and informed of the 
diverted-to number. 

The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 Session Progress 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
no indication 
Redirection number 

Address signal {Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 
Redirecting reason 

Mobile subscriber not reachable 
Generic notification 
call is diverting 

-[any boundary narne]-- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CFNL is performed 
INVITE(Call-ID B-C, IAM) 
1 83 Session Progress (Call-ID B-A, ACM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 



ETSI 



146 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS cfnl 014 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNL performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Diverted-to user is subscribed to the 
COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, a Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
CFNL is performed 

INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface 
Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 015 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CFNL performed in Network B, No restriction of the 
Redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Diverted-to user is not subscribed to 
the COLR service. 

Ensure that when user A calls user B, the call is forwarded not logged in to user 
C, if a Redirection number restriction parameter is present it is set to 
'Presentation allowed' in the encapsulated ANM contained in the 200 OK INVITE 
if ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 

Redirection number restriction not present 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
CFNL is performed 

INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 016 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 
not reachable to user C, user C is notified of call diversion and informed of the 
diverting number. 

The notification information is present in the encapsulated IAM contained in the 
Redirecting number 'presentation allowed' and Redirection information if 
ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 




• Served user releases his/her number to diverted-to user = Release diverting 




number information 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal {Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Mobile subscriber not reachable 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 

CFNL is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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Test case number 


SS cfnl 017 


Test case group 


SIP-SIP/Service/CFNL 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CFNL performed in Network B, Notification of diverted-to 
user Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CFNL, Served user releases his/her number to 
diverted-to user = Release diverting number information. 
Ensure that when user A calls user B, the call is forwarded on Mobile subscriber 
not reachable to user C, user C is notified of call diversion and informed of the 
diverting number. 

The notification information is present in the encapsulated IAM contained in the 
Redirecting number 'presentation restricted' and Redirection information if 
ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal {Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Mobile subscriber not reachable 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 

CFNL is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'Mobile subscriber not reachable'? 
Repeat this test in reverse direction. 
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7.1.5.6.5 Communication Deflection 



Test case number 


SS_cd_001 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 29 


Test purpose 


Communication deflection during alerting, basic rules. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CDa. 

Ensure that when user A calls user B, the call is deflected during alerting to user 
C. In the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) 
CDa is performed 
180 Ringing(Call-ID B-A) 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID B-C) 
200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) * 
Communication 
Apply post test routine 


Comments 


Check: CDa is successful. 

Check: In the active call state, ensure the property of speech. 
Check: Is the P-Asserted-ldentity present set to the identity of the originating 
user? 

Repeat this test in reverse direction. 




Test case number 


SS cd 002 


Test case group 


SIP-SIP/Service/CD I 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 


Test purpose 


Communication deflection immediate, basic rules. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. In 
the active call state, ensure the property of speech. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-IDA-B) * 
CDi is performed 
INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
200 OK INVITE(Call-ID C-B) 

ACK(Call-ID B-C) 
200 OK INVITE(Call-ID B-A) 

ACK(Call-IDA-B) * 
Communication 
Apply post test routine 


Comments 


Check: CDi is successful. 

Check: In the active call state, ensure the property of speech. 
Check: Is the P-Asserted-ldentity present set to the identity of the originating 
user? 

Repeat this test in reverse direction. 
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Test case number 


SS cd 003 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 AND SE 30 


Test purpose 


Communication Deflection immediate response, no notification. 

The user A and user C are in Network A. The user B is in network B and is 
provided with CFU, subscription option: Originating user receives notification that 
his communication has been diverted = No. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. 
Ensure that User A does not receive a 181 Call Is Being Forwarded message. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = No 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 

CDi is performed 

INVITE(Call-ID B-C) 
180 Ringing(Call-ID C-B) 
180 Ringing(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No notification regarding call forwarding in network B is received at the 

interconnection interface. 
Check: Is the cause parameter in the last entry is set to '480'. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 004 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 AND SE 30 


Test purpose 


Communication Deflection immediate response, originating user is 
notified. URI of the diverted-to user not received. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and ("Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" = No and. "Served user allows 
the presentation of his/her URI to originating user in diversion notification" = No. 
Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. 
Ensure that User A receives a 181 Call Is Being Forwarded message, user A is 
notified of call diversion and not informed of the diverted-to number and served 
user number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Originating user receives notification that his communication has been 

• Served user allows the presentation of his/her URI to originating user in 
diversion notification = No 


SIP Parameter 


181 Being Forwarded 
History-Info: 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=302>;index=1 , 
<sip: userC@networkA;cause=480?Privacy=history>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded and a History-Info header is received at the 
interconnection interface in both entries in the History-Info header a 
Privacy header is escaped value 'history'. 

Check: Is the cause parameter in the last entry is set to '480'? 

NOTE: The history entries can be accumulated in "one" History-Info header 
or each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 
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Test case number 


SS cd 005 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 AND SE 30 


Test purpose 


Communication Deflection immediate response, originating user is 
notified. URI from the diverted-to user received. 

The user A and user C are in network 1 . The user B is in network N2 and is 
provided with CFU Originating user receives notification that his communication 
has been diverted = Yes and "Served user allows the presentation of forwarded 
to URI to originating user in diversion notification" =Yes. 
Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C. 
Ensure that User A receives a 181 Call Is Being Forwarded message, user A is 
notified of call diversion and informed of the diverted-to number. 


Configuration 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes ^^^^^^^^^^^^^^^^^^^^^^^^ 

• Served user allows the presentation of diverted to URI to originating user in 
diversion notification = Yes 


SIP Parameter 


181 Being Forwarded 
History-Info: 

<sip:userB@networkB?Reason=SIP;cause=302>;index=1 , 
<sip: userC@networkA;cause=480>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: A 181 Being Forwarded is received at the interconnection interface. 
Check: A History-Info header is contained in the 181 with the URI of the 

diverted-to user. 
Check: Is the cause parameter in the last entry is set to '480'? 
NOTE: The history entries can be accumulated in "one" History-Info header 

or each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 006 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 AND SE 30 


Test purpose 


Communication Deflection immediate response, diverted-to user does not 
receive the URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 

■ 1 1 1 ■ 1 /-n i— 1 1 II /~\ 1 II ■ 1 ■ ■ ■ r 1 ■ /■ | I i— \ I ■ ,| 

provided with CFU Served user allows the presentation of his/her URI to the 
diverted-to user" = No. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C, 
user C is not informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = No 


SIP Parameter 


INVITE 

Request line contains ';cause=480' 
Hi story- Info: 

<sip:userB@networkB?Privacy=history&Reason=SIP;cause=302>;index=1 , 
<sip: userC@networkA;cause=480>;index=1 .1 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 

user B (served user) at the interconnection interface and a Privacy 

header is escaped set to 'history'. 
Check: Is the 'cause' parameter present in the Request line sent to user C 

(diverted-to user) set to '480'. 
Check: Is the cause parameter in the last entry is set to '480'? 
NOTE: The history entries can be accumulated in "one" History-Info header 

or each history entry is present in one single History-Info header. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 007 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 AND SE 30 


Test purpose 


Communication Deflection immediate response, diverted-to user receives 
the URI of the served user. 

The user A and user C are in network A. The user B is in network B and is 
provided with CFU Served user allows the presentation of his/her URI to 
diverted-to user" = Yes. 

Ensure that when user A calls user B which deflects the communication towards 
user C immediately (i.e. before alerting starts), the call is forwarded to user C, 
user C is informed of the forwarding number. 


Configuration 


Subscription options: 

• Served user allows the presentation of his/her URI to diverted-to user = Yes 


SIP Parameter 


INVITE 

Request line contains ';cause=480' 
Hi story- Info: 

<sip:userB@networkB?Reason=SIP;cause=302>;index=1 , 
<sip: userC@networkA;cause=480>;index=1 .1 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
Apply post test routine 


Comments 


Check: A History-Info header is received in the INVITE contains the URI of 
user B (served user) at the interconnection interface. 

Check: Is the 'cause' parameter present in the Request line sent to user C 
(diverted-to user) set to '480'? 

Check: Is the cause parameter in the last entry is set to '480'? 

NOTE: The history entries can be accumulated in "one" History-Info header 
or each history entry is present in one single History-Info header. 

Repeat this test in reverse direction. 




Test case number 


SS cd 008 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE29 


Test purpose 


Communication Deflection immediate response, unsuccessful UDUB. 

The user A and user C are in network A. The user B is in network B and is 
provided with CDi. 

Ensure that when user A calls user B, the call is deflected immediate to user C 
user C is user determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID B-A) 

ACK(Call-ID A-B) 
Apply post test routine 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 009 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 29 


Test purpose 


Communication Deflection immediate response, unsuccessful NDUB. 

The user A and user C are in network A. The user B is in network B. 

Ensure that when user A calls user B, the call is deflected immediate to user C 

and user C is network determined user busy. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
486 Busy Here(Call-ID C-B) 

ACK(Call-ID B-C) 
486 Busy Here(Call-ID B-A) 

ACK(Call-IDA-B) * 
Apply post test routine 


Comments 


Check: The dialogue is terminated by receiving a 486 Busy Here. 
Repeat this test in reverse direction 




Test case number 


SS cd 010 


Test case group 


SIP-SIP/Service/CD 


Reference 


4.5.2.6/[9] 


SELECTION EXPRESSION 


SE 29 AND SE 30 AND [Network A] SE 9 


Test purpose 


Communication Deflection immediate response, interaction with a not 
trusted network. 

The user A and user C are in network A. The user B is in network B and is 
provided with CD Originating user receives notification that his communication 
has been diverted = Yes ("Served user allows the presentation of forwarded to 
URI to originating user in diversion notification"=Yes, "diverting number is 
released to the diverted-to user"=Yes. 

Ensure that when user A calls user B, the call is deflected immediate response 
to user C, user A is notified of call diversion and not informed of the diverted-to 
number and user C is not informed of the forwarding number. 


Configuration 




SIP Parameter 


Subscription options: 

• Originating user receives notification that his communication has been 
diverted = Yes 

• Served user allows the presentation of forwarded to URI to originating 
user in diversion notification = No 




• Served user allows the presentation of his/her URI to originating user in 




diversion notification = No 
• Served user allows the presentation of his/her URI to the diverted-to 
user = No 


SIP Parameter 


INVITE: no History-Info header 




181 Being Forwarded no History-Info header 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
CDi is performed 
INVITE(Call-ID B-C) 
181 Being Forwarded(Call-ID B-A) 
Apply post test routine 


Comments 


Check: No History-Info header is received in the INVITE at the interconnection 
interface. 

Check: No History-Info header is received in the 181 Being Forwarded at the 

interconnection interface. 
Repeat this test in reverse direction. 
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Test case number 


SS cd 011 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification subscription 
options is set to presentation not allowed. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Calling user receives notification 
that his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is deflected to user C, user A is 
not notified about call diversion. 

The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = no 


SIP Parameter 


183 /180 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM/CPG 

Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation not allowed 
Redirecting reason 

Deflection immediate or Deflection during alerting 
Generic notification 
call is diverting 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A, ACM) in case CDa 
CD is performed 
INVITE(Call-ID B-C, IAM) 
1 83 / 1 80 (Call-ID B-A, ACM/CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 183 Session Progress received at the interconnection interface? 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator set to 'presentation not 
allowed'? 

Check: Is the Redirecting reason set to 'Deflection immediate' or 'Deflection 

during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 012 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification subscription 
options is set to presentation allowed without redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Calling user receives notification 
that his call has been diverted (forwarded or deflected) = yes, without diverted-to 
user number. 

Ensure that when user A calls user B, the call is deflected to user C, user A is 
notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, without diverted-to user number 


SIP Parameter 


183 /180 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM/CPG 

Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed without redirection number 
Redirecting reason 

Deflection immediate or Deflection during alerting 
Generic notification 
call is diverting 

-[any boundary name]-- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A) in case CDa 
CD is performed 
INVITE(Call-ID B-C, IAM) 
1 83 / 1 80 (Call-ID B-A, ACM/CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed without redirection number'? 
Check: Is the Redirecting reason set to 'Deflection immediate' or 'Deflection 

during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 013 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification subscription 
options is set to presentation allowed with redirection number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Calling user receives notification 
that his call has been diverted (forwarded or deflected) = yes, with diverted-to 
user number. 

Ensure that when user A calls user B, the call is deflected to user C, user A is 
notified of call diversion and informed of the diverted-to number. 
The notification information is present in the encapsulated ACM contained in the 
Redirection number and Call diversion information if SIP-I - ISUP/BICC 
interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Calling user receives notification that his call has been diverted (forwarded 
or deflected) = yes, with diverted-to user number 


SIP Parameter 


183 /180 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM/CPG 

Redirection number 

Address signal (Diverted-to user) 
Call diversion information 

Notification subscription options 

presentation allowed with redirection number 
Redirecting reason 

Deflection immediate or Deflection during alerting 
Generic notification 
call is diverting 

-[any boundary name]-- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A) in case CDa 
CD is performed 
INVITE(Call-ID B-C, IAM) 
1 83 / 1 80 (Call-ID B-A, ACM/CPG) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: 183 Session Progress is received at the interconnection interface. 
Check: Is an ACM encapsulated in the 1 83? 
Check: Is the Called party's status indicator set to 'no indication'? 
Check: Is the Redirection number present? 

Check: Is Notification subscription options indicator is set to 'presentation 

allowed with redirection number'? 
Check: Is the Redirecting reason set to 'Deflection immediate' or 'Deflection 

during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 014 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CD performed in Network B, Restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Diverted-to user is subscribed to 
the COLR service in Permanent mode. 

Ensure that when user A calls user B, the call is deflected to user C, a 
Redirection number restriction parameter is present set to 'Presentation 
restricted' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: 

• Connected user subscribed to COLR, Permanent = yes 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation restricted 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
180 Ringing (Call-ID B-A) in case CDa 
CD is performed 
INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 
Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction set to 'Presentation 

restricted'? 
Repeat this test in reverse direction. 



ETSI 



161 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS cd 015 


Test case group 


SIP-SIP/Service/CD 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 53 


Test purpose 


SIP-I support. CD performed in Network B, No restriction of the Redirection 
number. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 
of Network B and is provided with CDi or CDa, Diverted-to user is not subscribed 
to the COLR service. 

Ensure that when user A calls user B, the call is deflected to user C, if a 
Redirection number restriction parameter is present it is set to 'Presentation 
allowed' in the encapsulated ANM contained in the 200 OK INVITE if 
ISUP/BICC- SIP-I interworking is applicable in Network A. 


Configuration 


Subscription options: ^^^^^ 
• Connected user subscribed to COLR = no 


SIP Parameter 


200 OK 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Redirection number restriction 
Presentation allowed 
or 

Redirection number restriction not present 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(Call-ID A-B), IAM 
180 Ringing (Call-ID B-A) in case CDa 
CD is performed 
INVITE(Call-ID B-C) 
1 80 Ringing (Call-ID C-B, ACM) 
180 Ringing (Call-ID B-A) 
200 OK INVITE (Call-ID C-B, ANM) 
ACK (Call-ID B-C) 
200 OK INVITE (Call-ID B-A) 

ACK (Call-ID A-B) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a 200 OK INVITE received at the interconnection interface? 

Check: Is an ANM encapsulated in the 200 OK? 

Check: Is the ISUP/BICC Redirection number restriction present set to 

'Presentation allowed' or is the parameter absent? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 016 


Test case group 


SIP-SIP/Service/CD 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation allowed'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CDi or CDa, Served user releases his/her 

number to diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is deflected to user C, user C is 

notified of call diversion and informed of the diverting number. 

The notification information is present in the encapsulated 1AM contained in the 

Redirecting number 'presentation allowed' and Redirection information if 

ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: ^^^^^^^^^^^^^ ^^^^^^^^^ 




• Served user releases his/her number to diverted-to user = Release diverting 




number information 


SIP Parameter 


Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

1AM 

Redirecting number 

Address presentation restricted indicator 

presentation allowed 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation allowed 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Deflection immediate or Deflection during alerting 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A) in case CDa 
CD is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation allowed'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'Deflection immediate' or 'Deflection during alerting'? 
Repeat this test in reverse direction. 
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Test case number 


SS cd 017 


Test case group 


SIP-SIP/Service/CD 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 55 


Test purpose 


SIP-I support. CD performed in Network B, Notification of diverted-to user 
Redirecting number 'presentation restricted'. 

The user A and user C are in Network A. The user B is in the PSTN/PLMN part 

of Network B and is provided with CDi or CDa, Served user releases his/her 

number to diverted-to user = Release diverting number information. 

Ensure that when user A calls user B, the call is deflected to user C, user C is 

notified of call diversion and informed of the diverting number. 

The notification information is present in the encapsulated IAM contained in the 

Redirecting number 'presentation restricted' and Redirection information if 

ISUP/BICC - SIP-I interworking is applicable in Network B. 


Configuration 


Subscription options: 

• Served user releases his/her number to diverted-to user = Do not release 
diverting numberinformation 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Redirecting number 

Address presentation restricted indicator 

presentation restricted 
Address signal (Diverting user) 
Original called number 

Address presentation restricted indicator 

presentation restricted 
Address signal 
Redirection information 

Original Redirection Reason 

unknown 
Redirecting indicator 
Redirection counter 
Redirecting reason 

Deflection immediate or Deflection during alerting 

-[any boundary name]- 


Message flow 

SIP (Network A) 


Interconnection Interface SIP (Network B) 
INVITE(Call-ID A-B) 
180 Ringing (Call-ID B-A) in case CDa 
CD is performed 
^H(Call-ID B-C, IAM) 
Apply post test routine 


Comments 


Originating user in Network A establishes a call to user in Network B. Network B 
performs the diversion to a user in Network A 

Check: Is a INVITE request received at the interconnection interface? 
Check: Is an IAM encapsulated in the INVITE? 

Check: Is the Redirecting number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Original called number present and the Address presentation 
restricted indicator is set to 'presentation restricted'? 

Check: Is the Redirection number present? 

Check: Is Redirection information present and the Redirecting reason is set to 

'Deflection immediate' or 'Deflection during alerting'? 
Repeat this test in reverse direction. 
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7.1.5.7 Conference (CONF) 



Test case number 


SS conf 001 


Test case group 


SIP-SIP/Service/CONF 


Reference 


4.5.2/[10] 


SELECTION EXPRESSION 


([Network A] SE 1 1 AND [Network B] SE 1 1) AND SE 31 


Test purpose 


3 Party establishment using the REFER method. 

User B1 and user B2 are located in network B, user A is located in network A. A 
confirmed session from user A to user B1 is set on hold; a confirmed session 
from user A to user B2 is set on hold. 

• Ensure that when user A refers to user B1 to invite to the conference, the 
user B1 sends a NOTIFY to user A indicating Tying'. The user B1 sends an 
INVITE request to the conference focus in network A. Is the request is 
confirmed, user B1 sends a NOTIFY indicating '200 OK'. User A terminates 
the original dialogue. 

• Ensure that when user A refers to user B2 to invite to the conference, the 
user B2 sends a NOTIFY to user A indicating Tying'. The user B2 sends an 
INVITE request to the conference focus in network A. Is the request is 
confirmed, user B2 sends a NOTIFY indicating '200 OK'. User A terminates 
the original dialogue. 


Configuration 




SIP Parameter 


REFER(user B1) 

Refer-To: <uri of conference focus;method=INVITE > 

NOTIFY(B1, 100) 

Content-Type: message/sipfrag 
SIP/2.0 100 

INVITE: Request URI: uri of conference focus 
From: user B1 

NOTIFY(B1, 200) 

Content-Type: message/sipfrag 
SIP/2.0 200 OK 

REFER(user B2) 

Refer-To: <uri of conference focus;method=INVITE > 

NOTIFY(B2, 100) 

Content-Type: message/sipfrag 
SIP/2.0 100 

INVITE: Request URI: uri of conference focus 
From: user B2 

NOTIFY(B2, 200) 

Content-Type: message/sipfrag 
SIP/2.0 200 OK 
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Message flow 








SIP (Network A) 




Interconnection Interface 


SIP (Network B) 


Establish a confirmed session to user B1 from Network A to Network B and put it on hold 


Establish a confirmed session to user B2 from Network A to Network B and put it on hold 


User A establishes a 3PTY conversation 






REFER(user B1) 






202 Accepted 






NOTIFY(B1, 100) 






200 OK NOTIFY 






INVITE(focus, user B1) 






200 INVITE 






ACK 






NOTIFY(B1, 200) 






200 OK NOTIFY 






BYE(user B1) 






200 OK BYE 






REFER(user B2) 






202 Accepted 






NOTIFY(100) 






200 OK NOTIFY 






INVITE(focus, user B2) 






200 INVITE 






ACK 






NOTIFY(B2, 200) 






200 OK NOTIFY 






BYE(user B2) 






200 OK BYE 






Apply post test routine 




Comments 


User A establishes a 3PTY conversation after the confirmed communication to 




user B1 and B2 are set on hold 






Check: 


The Refer-To header in the REFER method sent to user B1 and B2 






contains the URI of the conference focus and is the method parameter 






set to INVITE'. 






Check: 


The NOTIFY after the REFER request contains the 'SIP/2.0 100' 






message body. 






Check: 


The INVITE request is sent by user B1 and user B2 to the conference 






focus the Request URI is used from the Refer-To header of the 






received REFER request. 






Check: 


The NOTIFY after the REFER request contains the 'SIP/2.0 200 OK' 






message body. 






Check: 


The original session is terminated by user A. 




Repeat this test in reverse direction. 
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Test case number 


SS conf 002 


Test case group 


SIP-SIP/Service/CONF 


Reference 


4.5.2/[10], 4.7.2.9.7/[20] 


SELECTION EXPRESSION 


[Network A] SE 12 AND SE 31 


Test purpose 


3 Party establishment using relNVITE performed by the AS in network A. 

User B1 and user B2 are located in network B, user A is located in network A. A 
confirmed session from user A to user B1 is set on hold; a confirmed session 
from user A to user B2 is set on hold. 

• Ensure that user A can invite user B1 to the conference by sending a 
relNVITE request. 

• Ensure that user A can invite user B2 to the conference by sending a 
relNVITE request. 


Configuration 




SIP Parameter 


INVITE <B1> 
From: <userA> 
To: <userB1> 
Call-ID: A-B1 

P-Asserted-ldentity: <userA> 
SDP: a=sendrecv 

INVITE <B2> 
From: <userA> 
Call-ID: A-B2 
To: <userB2> 

P-Asserted-ldentity: <userA> 
SDP: a=sendrecv 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
Establish a confirmed session to user B1 from Network A to Network B and put it on hold 
Establish a confirmed session to user B2 from Network A to Network B and put it on hold 
User A establishes a 3PTY conversation 

INVITE(Call-ID A-B1) 
200 INVITE 
ACK 




INVITE(Call-ID A-B2) * 
200 INVITE 
ACK 

Apply post test routine 


Comments 


User A establishes a 3PTY conversation after the confirmed communication to 
user B1 and B2 are set on hold 

Check: An INVITE is sent to user B1 and user B2 indicating a new IP address 

in the 'c' line of the SDP. 
Check: The 'a' line indicates 'sendrecv'. 
Repeat this test in reverse direction. 
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Test case number 


SS conf 003 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Served user establishes a 3 Party communication. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and sets it on HOLD. User A establishes a confirmed 
communication with a User B2 in Network B. 
Ensure that when User A establishes a 3 PTY communication: 

• an INFO request is sent to User B1 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to conference 
established'; 

• an INFO request is sent to User B2 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'conference 
established'. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INFO<B1> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

Conference established 

INFO <B2> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

Conference established 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
Establish a confirmed session from User A in Network A to user B1 in Network B and put it on hold 
Establish a confirmed session from User A in Network A to user B2 in Network B 

INFO(Call-ID A-B1, CPG) 
200 INFO 




INFO(Call-ID A-B2, CPG) 

200 INFO 
Apply post test routine 


Comments 


User A establishes confirmed communication to user B1 in Network B and sets it 
on hold 

User A establishes a confirmed communication to user B2 in Network B 
User A invokes the 3PTY communication 

Check: Is an INFO request sent to user B1 and user B2 in Network B? 
Check: Is a ISUP/BICC CPG message encapsulated in the INFO request to 

both remote users in Network B? 
Check: Is the Generic Notification parameter in the encapsulated CPG in both 

INFO set to 'Conference established'? 
Repeat this test in reverse direction. 



ETSI 



168 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS conf 004 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Served user disconnects one of the remote users. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and sets it on HOLD. User A establishes a confirmed 
communication with a User B2 in Network B. User A invokes 3PTY conversation. 
Ensure that when User A disconnects the previous active user: 

• a BYE request is sent to User B1 in Network B; 

• an INFO request is sent to User B2 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'Conference 
disconnected'. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INFO <B2> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

Conference disconnected 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
Establish a confirmed session from User A in Network A to user B1 in Network B and put it on hold 
Establish a confirmed session from User A in Network A to user B2 in Network B 
User A establishes a 3PTY conversation 

BYE(Call-ID A-B1, REL) 
200 INFO 




INFO(Call-ID A-B2, CPG) 

200 INFO 
Apply post test routine 


Comments 


User A establishes a 3PTY conversation with user B1 and user B2 located in 
Network B 

User A disconnects the communication with user B1 in Network B (previous on 
hold) 

Check: Is a BYE request is sent to user B1 in Network B? 

Check: Is a ISUP/BICC CPG message encapsulated in the INFO request to 

user B2 in Network B? 
Check: Is the Generic Notification parameter in the encapsulated CPG in the 

INFO sent to user B2 set to 'Conference disconnected'? 
Repeat this test in reverse direction. 
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Test case number 


SS conf 005 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Served user splits the 3 Party communication. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and sets it on HOLD. User A establishes a confirmed 
communication with a User B2 in Network B. User A invokes 3PTY conversation 
Ensure that when User A splits the 3 PTY communication: 

• an INFO request is sent to User B1 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to Conference 
disconnected'; 

• an INFO request is sent to User B2 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'Conference 
disconnected'. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INFO<B1> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

Conference disconnected 

INFO <B2> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

Conference disconnected 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
Establish a confirmed session from User A in Network A to user B1 in Network B and put it on hold 
Establish a confirmed session from User A in Network A to user B2 in Network B 
User A establishes a 3PTY conversation 

INFO(Call-ID A-B1, CPG) 
200 INFO 




INFO(Call-ID A-B2, CPG) 

200 INFO 
Apply post test routine 


Comments 


User A establishes confirmed communication to user B1 in Network B and sets it 
on hold 

User A establishes a confirmed communication to user B2 in Network B 
Check: Is an INFO request sent to user B1 and user B2 in Network B? 
Check: Is a ISUP/BICC CPG message encapsulated in the INFO request to 

both remote users in Network B? 
Check: Is the Generic Notification parameter in the encapsulated CPG in both 

INFO set to 'Conference established'? 
Repeat this test in reverse direction. 
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Test case number 


SS conf 006 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Establishment of aCONF conversation. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A establishes a confirmed communication with a User 
B1 in Network B and invokes the CONF communication. 
Ensure that when User A invokes the CONF communication: 

• an INFO request is sent to User B1 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'conference 
established' when the conference is invoked. 

User A establishes a confirmed communication with a User B2 in Network B. 
Ensure when User A adds the user B2 to the established conference: 
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• an INFO request is sent to User B1 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'Other party; 

• an INFO request is sent to User B2 in Network B and a ISUP/BICC CPG 
is encapsulated the Generic Notification is set to 'conference 
established' when the user is added to the conference. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INF01 <B1> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 

conference established 

INF02<B1> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Generic Notification 
Other party added 

INFO <B2> 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

Generic Notification 

conference established 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
Establish a confirmed session from User A in Network A to user B1 in Network B 
User A establishes a CONF conversation 

INF01 (Call-ID A-B1, CPG) 
200 INFO 


Establish a confirmed session from User A in Network A to user B2 in Network B and add to the 

conference 

INF02(Call-ID A-B2, CPG) 
200 INFO 




INFO(Call-ID A-B2, CPG) 

200 INFO 
Apply post test routine 
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Comments 



User A establishes confirmed communication to user B1 in Network B and 
invoke the CONF communication 

Check: Is an INFO request sent to user B1 and in Network B and Is a 

ISUP/BICC CPG message encapsulated in the INFO request and the 
Generic Notification is set to 'conference established'? 

User A establishes a confirmed communication to user B2 in Network B and add 

it to the conference. 

Check: Is an INFO request sent to user B2 Network B and a ISUP/BICC CPG 
message encapsulated the Generic Notification is set to 'conference 
established? 

Check: Is an INFO request sent to user B1 Network B and a ISUP/BICC CPG 
message encapsulated the Generic Notification is set to 'Other party 
added? 

Repeat this test in reverse direction. 



Test case number 


SS_conf_007 


i esi case group 


QIP QIP/Qor\/ipo/rnMF 

oir -oir /oervice/OwiNir 


Reference 


5.4/[24] 


OCI CPTIAM CYDDCQQIOM 
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Test purpose 


SIP-I/ISUP interworking. Isolation and Reattachment of one party of the 
conference. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A invokes a CONF communication with user B1 and 
user B2 in Network B. 

Ensure that when User A isolates one remote party (B1) from the CONF 
communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'isolated' in the encapsulated ISUP/BICCCPG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party isolated' in the encapsulated 
ISUP/BICCCPG. 

Ensure that when User A reattaches one remote party (B1) to the CONF 
communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'reattached' in the encapsulated ISUP/BICCCPG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party reattached' in the encapsulated 
ISUP/BICCCPG. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INF01 <B1> 

CPG 

Generic Notification= isolated 

INF02<B1> 

CPG 

Generic Notification= Other party isolated 

INF01 <B2> 

CPG 

Generic Notification= reattached 

INF02 <B2> 

CPG 

Generic Notification= Other party reattached 
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Message flow 




SIP (Network A) 


Interconnection Interface SIP (Network B) 


Establish a CONF communication with User B1 and User B2 in Network B 


User A isolates User B1 from the CONF conversation 




INF01 (Call-ID A-B1, CPG) 




200 INFO 




INF01 (Call-ID A-B2, CPG) 




200 INFO 


User A reattaches User B1 to the CONF conversation 




INF02(Call-ID A-B2, CPG) 




200 INFO 




INF02(Call-ID A-B2, CPG) 




200 INFO 




Apply post test routine 


Comments 


User A Invokes a CONF conversation with User B1 and User b2 in Network B 

User A splits user B1 in Network B from the CONF conversation 

Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'isolated' in the encapsulated CPG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party isolated' in the encapsulated CPG? 
User A reattaches user B1 in Network B to the CONF conversation 
Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'reattached' in the encapsulated CPG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party reattached' in the encapsulated CPG? 
Repeat this test in reverse direction 
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Test case number 


SS conf 008 


Test case group 


SIP-SIP/Service/CONF 


Reference 


5.4/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 56 


Test purpose 


SIP-I/ISUP interworking. Splitting and Adding of a party. 

Served User A is located in Network A and ISUP/BICC - SIP-I interworking 
applies in Network A. User A invokes a CONF communication with user B1 and 
user B2 in Network B. 

Ensure that when User A split one remote party (B1) from the CONF 
communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to 'conference disconnected' in the encapsulated 
ISUP/BICCCPG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party split' in the encapsulated 
ISUP/BICCCPG. 

Ensure that when User A adds one remote party (B1) to the CONF 
communication: 

• an INFO request is sent to User B1 in Network B and the Generic 
Notification is set to Conference established in the encapsulated 
ISUP/BICCCPG; 

• an INFO request is sent to User B2 in Network B and the Generic 
Notification is set to 'Other party added' in the encapsulated 
ISUP/BICCCPG. 


Configuration 


ISUP/BICC interworking applies in Network A 

User in Network A is subscribed to the 3PTY supplementary service 


SIP Parameter 


INF01 <B1> 

CPG 

Generic Notification= conference disconnected 

INF02<B1> 

CPG 

Generic Notification=Other party split 

INF01 <B2> 

CPG 

Generic Notification=Conference established 

INF02 <B2> 

CPG 

Generic Notification= Other party added 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
Establish a CONF communication with User B1 and User B2 in Network B 
User A isolates User B1 from the CONF conversation 

INF01 (Call-ID A-B1, CPG) 

200 INFO 
INF01 (Call-ID A-B2, CPG) 

200 INFO 

User A reattaches User B1 to the CONF conversation 

INF02(Call-ID A-B2, CPG) 

200 INFO 
INF02(Call-ID A-B2, CPG) 

200 INFO 
Apply post test routine 


Comments 


User A Invokes a CONF conversation with User B1 and User b2 in Network B 

User A splits user B1 in Network B from the CONF conversation. 

Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'conference disconnected' in the encapsulated CPG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party split' in the encapsulated CPG? 
User A adds user B1 in Network B to the CONF conversation. 
Check: Is an INFO request sent to user B1 and the Generic notification is set 

to 'Conference established' in the encapsulated CPG? 
Check: Is an INFO request sent to user B2 and the Generic notification is set 

to 'Other party added' in the encapsulated CPG? 
Repeat this test in reverse direction 
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7.1 .5.8 Anonymous Communication Rejection (ACR) and Communication Barring 
(CB) 



Test case number 


SS acr-cb 001 


Test case group 


SIP-SIP/Service/ACR-CB 


Reference 


4.5.2.6/[12] 


SELECTION EXPRESSION 


SE32 I 


Test purpose 


Call Barring performed in network B for user B. 

User A is located in network A and user B is located in network B and is 
subscribed to the Incoming Call Barring service. 

Ensure that a communication from user A is rejected in network B by sending a 
603 Decline due to the Call Barring service of user B. 


Configuration 


User B is subscribed to the incoming Call Barring service (e.g. user A in a black 
list) 


SIP Parameter 


INVITE 

P-Asserted-ldentity: <URI of user A> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

603 (Decline) 
ACK 


Comments 


Check: Is the P-Asserted-ldentity present? 

Check: Is the communication rejected by sending a 603 (Decline) final 

response sent to user A? 

Repeat this test in reverse direction. 




Test case number 


SS acr-cb 002 


Test case group 


SIP-SIP/Service/ACR-CB 


Reference 


4.5.2.6/[12] 


SELECTION EXPRESSION 


SE33 


Test purpose 


ACR performed in network B for user B. 

User A is located in network A and user B is located in network B and is 
subscribed to the Anonymous Communication rejection service. 
Ensure that an anonymous communication from user A is rejected in network B 
by sending a 403 Anonymity Disallowed final response due to the Anonymous 
Communication Rejection service of user B. 


Configuration 


User B is subscribed to the Anonymous Communication Rejection service 


SIP Parameter 


INVITE 

P-Asserted-ldentity: <URI of user A> 
Privacy: id 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

4- 433 (Anonymity Disallowed) 
ACK 


Comments 


Check: Is the P-Asserted-ldentity present? 
Check: Is the Privacy header set to 'id'? 

Check: Is the communication rejected by sending a 433 (Anonymity 

Disallowed) final response sent to user A? 
Repeat this test in reverse direction. 
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Test case number 


SS acr-cb 003 


Test case group 


SIP-SIP/Service/ACR-CB 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 57 


Test purpose 


SIP-I interworking. ACR performed in network B for user B. 

User A is located in network A and user B is in the PSTN/PLMN part of Network 
B and is subscribed to the Anonymous Communication rejection service. 
Ensure that an anonymous communication from user A is rejected in network B 
by sending a 603 Decline final response due to the Anonymous Communication 
Rejection service of user B. A ISUP/BICC REL is present in the 603 the Cause 
indicator value is set to '21 ' if SIP-I - ISUP/BICC interworking is applicable in 
Network B. 


Configuration 


User B is subscribed to the Anonymous Call Rejection service 


SIP Parameter 


INVITE 

P-Asserted-ldentity: <URI of user A> 
Privacy: id 

433 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL: 

Cause indicator 
Cause = 21 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
603 Decline (REL) 
ACK 


Comments 


Check: Is the P-Asserted-ldentity present? 
Check: Is the Privacy header set to 'id'? 

Check: Is the communication rejected by sending a 603 Decline final 

response sent to user A? 
Check: Is an ISUP/BICC REL is present in the 603 and the cause value is set 

to '21'? 

Repeat this test in reverse direction. 
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7.1 .5.9 Closed User Group (CUG) 



Test case number 


SS cug 001 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user +OA to terminating user no CUG. 

An originating user in a CUG Outgoing Access allowed calls to a user not in a 
CUG. The session establishment is successful. 


Configuration 


Originating user: CUG, outgoing access allowed 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
<...cug> 

<. . .networklndicator>01 </. . . networklndicator 
<. . .networklndicator>23</. . . networklndicator 
<. . . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 
<. . .CugCommunicationlndicator>1 0</. . .cugCommunicationlndicator> 
<...:cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 0' as a 'cug' child element? 
Check: Is the session setup not rejected? 
Repeat this test in reverse direction. 

NOTE: The networklndicator element value and the cuglnterlockBinaryCode 
element value are examples. 
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Test case number 


SS cug 002 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4, 4.5.2.10/[13] 


SELECTION EXPRESSION 


SE 34 


Test purpose 


Originating user -OA to terminating user no CUG. 

An originating user in a CUG Outgoing Access not allowed calls to a user not in 
a CUG. The session establishment is not successful, a 403 (Forbidden) 
response is sent. 


Configuration 


Originating user: CUG, outgoing access not allowed 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...:cug> 

<. . .networklndicator>01 </. . .networklndicator 
<. . .networklndicator>23</. . .networklndicator 
<. . . .uglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 
<. . .cugCommunicationlndicator>1 1 </. . .cugCommunicationlndicator> 
<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
403 (Forbidden) 
ACK 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Is the handling parameter in the Content-Disposition header set to 

required? 

Check: Contains the XML body in the INVITE a 'cug' element? 

Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 1 ' as a 'cug' child element? 
Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network? 
Repeat this test in reverse direction. 

NOTE: The networklndicator element value and the cuglnterlockBinaryCode 
element value are examples. 
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Test case number 


SS cug 003 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4, 4.5.2.10/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user -OA to terminating user -IA. 

An originating user in a CUG Outgoing Access not allowed calls to a user in the 
same CUG Incoming Access not allowed. The session establishment is 
successful. 


Configuration 


Originating user: CUG, outgoing access not allowed 
Terminating user: CUG incoming access not allowed 
User in network A and user in network B are in the same CUG 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...cug> 

<. . .networklndicator>01 </. . .networklndicator 
<. . .networklndicator>23</. . .networklndicator 
<. . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 
<. . .cugCommunicationlndicator>1 1 </. . .cugCommunicationlndicator> 
<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Is the handling parameter in the Content-Disposition header set to 

required? 

Check: Contains the XML body in the INVITE a 'cug' element? 

Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 1 ' as a 'cug' child element? 
Check: Is the session setup not rejected? 
Repeat this test in reverse direction. 

NOTE: The networklndicator element value and the cuglnterlockBinaryCode 
element value are examples. 
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Test case number 


SS cug 004 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4, 4.5.2.10/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user in a CUG to terminating user -IA. 

An originating user in a CUG calls to a user in a different CUG Incoming Access 
not allowed. The session establishment is not successful, a 403 (Forbidden) 
response is sent. 


Configuration 


User in network A and user in network B are not in the same CUG 
Terminating user: CUG incoming access not allowed 


SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= requiredv 

<...cug> 

<. . .networklndicator>01 </. . .networklndicator 
<. . .networklndicator>23</. . .networklndicator 
<. . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 
<. . .cugCommunicationlndicator>..</. . .cugCommunicationlndicator> 
<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

403 (Forbidden) 
ACK 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Contains the XML body in the INVITE a 'cug' element? 
Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 0' or '1 1 'as a 'cug' child element? 
Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network? 
Repeat this test in reverse direction. 

NOTE: The networklndicator element value and the cuglnterlockBinaryCode 
element value are examples. 




Test case number 


SS cug 005 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.1 0/[1 3] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user no CUG to terminating user +IA. 

An originating user not in a CUG calls to a user in a CUG Incoming Access 
allowed. The session establishment is successful. 


Configuration 


Terminating user: CUG incoming access allowed 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network. 
Repeat this test in reverse direction. 



ETSI 



180 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS cug 006 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.1 0/[1 3] 


SELECTION EXPRESSION 


[Network A] SE 34 AND NOT [Network B] SE 34 


Test purpose 


Originating user no CUG to terminating user -IA. 

An originating user not in a CUG calls to a user in a CUG Incoming Access not 
allowed. The session establishment is not successful, a 403 (Forbidden) 
response is sent. 


Configuration 


User in Network B in a CUG incoming access not allowed 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
403 (Forbidden) 
ACK 


Comments 


Check: Is the session setup rejected? A 403 (Forbidden) final response is sent 

by the terminating network. 
Repeat this test in reverse direction. 




Test case number 


SS cug 007 1 


Test case group 


SIP-SIP/Service/CUG 


Reference 


4.5.2.4/[13] 


SELECTION EXPRESSION 


SE34 


Test purpose 


Originating user -OA, network B does not support CUG. 

An originating user in a CUG Outgoing Access not allowed calls to a user in 
network B. Network B does not support CUG. The session establishment is not 
successful, a 4xx unsuccessful final response is sent. 


Configuration 




SIP Parameter 


INVITE: 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...cug> 

<. . .networklndicator>01 </. . .networklndicator 
<. . .networklndicator>23</. . .networklndicator 
<. . .cuglnterlockBinaryCode>0F03</. . .cuglnterlockBinaryCode> 
<. . .cugCommunicationlndicator>1 0</. . .cugCommunicationlndicator> 
<...cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

4- 4xx/501 Not Implemented 
ACK 


Comments 


Check: Is the Content-Type in The INVITE set to 

application/vnd.etsi.cug+xml? 
Check: Is the handling parameter in the Content-Disposition header set to 

required? 

Check: Contains the XML body in the INVITE a 'cug' element? 

Check: Contains the XML body in the INVITE a 'networklndicator' element as 

a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cuglnterlockBinaryCode' 

element as a 'cug' child element? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 1 ' as a 'cug' child element? 
Check: Is the session setup rejected by sending an unsuccessful final 

response? 
Repeat this test in reverse direction. 

NOTE: The networklndicator element value and the cuglnterlockBinaryCode 
element value are examples. 
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Test case number 


SS cug 008 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. CUG call with outgoing access allowed. 

User A is located in the PSTN part of Network A and ISUP/BICC interworking 
applies in Network A. ensure that when user A is in a CUG 'outgoing access 
allowed' calls user B in Network B. The call is successful. There is a Optional 
forward call indicator the CUG Call Indicator Outgoing access allowed present 
in the encapsulated IAM sent to Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access allowed 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 


Comments 


User A in the PSTN part of Network A calls user B in Network B 
Check: Is an IAM encapsulated in the INVITE request sent from Network A to 
Network B? 

Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

IAM? 

NOTE: CUG outgoing access allowed can appear like a basic call. 
Repeat this test in reverse direction. 
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Test case number 


SS cug 009 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. CUG call with outgoing access not allowed. 

User A is located in the PSTN part of Network A and ISUP/BICC interworking 
applies in Network A. ensure that when user A is in a CUG 'outgoing access 
allowed' calls user B in Network B. The call is successful. There is a Optional 
forward call indicator the CUG Call Indicator Outgoing access not allowed 
present in the encapsulated IAM sent to Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 


Comments 


User A in the PSTN part of Network A calls user B in Network B 
Check: Is an IAM encapsulated in the INVITE request sent from Network A to 
Network B? 

Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

IAM? 

Repeat this test in reverse direction. 
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Test case number 


SS cug 010 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47 AND SE 58) AND ([Network B] SE 17 AND SE 
47 AND SE 58) 


Test purpose 


SIP-I/ISUP interworking. CUG call with outgoing access not allowed (both 
user in the same CUG). 

User A in a CUG is located in the PSTN part of Network A and ISUP/BICC 
interworking applies in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BICC interworking applies in the same CUG. Ensure that when user 
A is in a CUG 'outgoing access not allowed' calls user B in Network B. The call is 
successful. There is a Optional forward call indicator the CUG Call Indicator 
Outgoing access not allowed present in the encapsulated IAM sent to 
Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 

• User in PSTN/PLMN part of Network B in a CUG 

• User A and User B are in the same CUG 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 


Comments 


User A in the PSTN part of Network A calls user B in the PST/PLMN part of 
Network B 

Check: Is an IAM encapsulated in the INVITE request sent from Network A to 
Network B? 

Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

IAM? 

Check: Is the call setup successful? 
Repeat this test in reverse direction. 



ETSI 



184 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS cug 011 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47 AND SE 58) AND ([Network B] SE 17 AND SE 
47 AND SE 58) 


Test purpose 


SIP-I/ISUP interworking. CUG call to a CUG user incoming access not 
allowed (both user in the same CUG). 

User A in a CUG is located in the PSTN part of Network A and ISUP/BICC 
interworking applies in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BICC interworking applies in the same CUG. Ensure that when user 
A is in a CUG 'outgoing access not allowed' calls CUG user B in Network B. The 
call is successful. There is a Optional forward call indicator the CUG Call 
Indicator Outgoing access not allowed present in the encapsulated IAM sent 
to Network B. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 

• User in PSTN/PLMN part of Network B in a CUG incoming access not 
allowed 

• User A and User B are in the same CUG 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 


Comments 


User A in the PSTN/PLMN part of Network A calls user B in Network B 
User B in the PSTN/PLMN part of Network B. 

Check: Is an IAM encapsulated in the INVITE request sent from Network A to 
Network B? 

Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

IAM? 

Check: Is the call setup successful? 
Repeat this test in reverse direction. 
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Test case number 


SS cug 012 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47 AND SE 58) AND ([Network B] SE 17 AND SE 
47 AND SE 58) 


Test purpose 


SIP-I/ISUP interworking. CUG call to a CUG user incoming access not 
allowed (both user in different CUG). 

User A in a CUG is located in the PSTN part of Network A and ISUP/BICC 
interworking applies in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BICC interworking applies in different CUG. Ensure that when user 
A is in a CUG 'outgoing access not allowed' calls CUG user B in Network B. 
There is a Optional forward call indicator the CUG Call Indicator Outgoing 
access not allowed present in the encapsulated IAM sent to Network B. The 
call is rejected with a 500 (Server Internal error) final response. A ISUP/BICC 
REL is encapsulated and the Cause value is set to '87'. 


Configuration 


• User in PSTN/PLMN part of Network A in a CUG outgoing access not 
allowed 

• User in PSTN/PLMN part of Network B in a CUG incoming access not 
allowed 

• User A and User B are in different CUG 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
--[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

Optional Forward call indicator 

CUG Call Indicator 

Outgoing access not allowed 
CUG interlock code 

-[any boundary name]- 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause indicators 

Cause value 
87 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

500 Server Internal error(REL) 
ACK 


Comments 


User A in the PSTN/PLMN part of Network A calls user B in Network B 
User B in the PSTN/PLMN part of Network B. 

Check: Is an IAM encapsulated in the INVITE request sent from Network A to 
Network B? 

Check: Is the Optional forward call indicator present, the CUG Call Indicator is 

set to 'Outgoing access not allowed'? 
Check: Is the CUG interlock code parameter present in the encapsulated 

IAM? 

Check: Is the call rejected with a 500 final response and a ISUP/BICC REL is 

encapsulated and the cause value is set to 87? 
Repeat this test in reverse direction. 
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Test case number 


SS cug 013 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 58 


Test purpose 


SIP-I/ISUP interworking. Call to a CUG user incoming access not allowed. 

User A is located in Network A. User B in a CUG Incoming access not allowed is 
located in the PSTN/PLMN part and SIP-I - ISUP/BICC interworking applies. 
Ensure that when user A calls user B in Network B. The call is rejected with a 
500 (Server Internal error) final response. A ISUP/BICC REL is encapsulated 
and the Cause value is set to '87'. 


Configuration 


• User in PSTN/PLMN part of Network B in a CUG incoming access not 
allowed 


SIP Parameter 


500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause indicators 

Cause value 
87 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

500 Server Internal error(REL) 
ACK 


Comments 


User A in Network A calls user B in Network B 
User B in the PSTN/PLMN part of Network B. 

Check: Is the call rejected with a 500 final response and a ISUP/BICC REL is 

encapsulated and the cause value is set to 87? 
Repeat this test in reverse direction. 




Test case number 


SS cug 014 I 


Test case group 


SIP-SIP/Service/CUG 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 58 \ 


Test purpose 


SIP-I/ISUP interworking. Call to a CUG user incoming access allowed. 

User A is located in Network A. User B is located in the PSTN/PLMN part and 
SIP-I - ISUP/BICC interworking applied. Ensure that when user A calls CUG user 
B Incoming access allowed in Network B. The call is successful. 


Configuration 


• User in PSTN/PLMN part of Network B in a CUG incoming access allowed 


SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 


Comments 


User A in Network A calls user B in Network B 
User B in the PSTN/PLMN part of Network B. 
Check: Is the call setup successful? 
Repeat this test in reverse direction. 
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7.1.5.10 Communication Waiting (CW) 



Test case number 


SS cw 001 ! 


Test case group 


SIP-SIP/Service/CW 


Reference 


4.5.5.2/[15] 


SELECTION EXPRESSION 


SE35 


Test purpose 


Call Waiting indication in 180 response. 

User A is located in network A, user B is located in network B and subscribed to 
the communication Waiting service. 

Ensure that when user A calls user B, user A receives the 'communication 
Waiting indication' in the 180 Ringing provisional response if the user B is NDUB 
orUDUB. 


Configuration 


User B subscribed to the CW service 


SIP Parameter 


180: 

Alert-Info: <urn:alert:service:call-waiting> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: Is an Alert-Info header present in the 180 Ringing Response and is the 

value set to '<urn:alert:service:call-waiting>'? 
Repeat this test in reverse direction. 




Test case number 


SS cw 002 


Test case group 


SIP-SIP/Service/CW ! 


Reference 


4.5.5.2/[15] 


SELECTION EXPRESSION 


SE35 AND SE 36 


Test purpose 


Call rejected after timeout TAS-CW. 

User A is located in network A, user B is located in network B and subscribed to 
the communication Waiting service. 

Ensure that when user A calls user B, user A receives the 'communication 
Waiting indication' in the 180 Ringing provisional response if the user B is NDUB 
or UDUB. After timeout TAS-CW network B sends a 480 (Temporarily 
unavailable) response toward user A and the Reason header field is set to '19'. 


Configuration 




SIP Parameter 


180: 

Alert-Info: <urn:alert:service:call-waiting> 
480: 

Reason: Q.850 ;cause=19 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Timeout TAS-CW 
480 (Temporarily unavailable) 
ACK 


Comments 


Check: Is an Alert-Info header present in the 180 Ringing Response and is the 

value set to '<urn:alert:service:call-waiting>'? 
Check: Is a Reason header present in the 480 Response and is the protocol is 

set to 'Q.850' and the cause parameter set to '19'? 
Repeat this test in reverse direction. 
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Test case number 


SS cw 003 


Test case group 


SIP-SIP/Service/CW 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 59 


Test purpose 


SIP-I support. Call Waiting indication in 180 with encapsulated ACM. 

User A is located in network A, user B is located in the PSTN/PLMN part of 
network B and subscribed to the Call Waiting service. 
Ensure that when user A calls user B, an encapsulated ISUP/BICC ACM 
Generic notification 'call is a waiting call' is present in the 180 Ringing provisional 
response if the user B is NDUB. 


Configuration 


User B subscribed to the CW service 


SIP Parameter 


180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

Backward call indicator 

Called party's status indicator 
subscriber free 
Generic notification 

Notification indicator 
call is a waiting call 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC ACM present in the 180 provisional response and 

the Generic notification is set to 'call is a waiting cal'? 
Repeat this test in reverse direction. 




Test case number 


SS cw 004 


Test case group 


SIP-SIP/Service/CW 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 59 


Test purpose 


SIP-I support. Call Waiting indication in 180 with encapsulated CPG. 

User A is located in network A, user B is located in the PSTN/PLMN part of 
network B and subscribed to the Call Waiting service. 

Ensure that when user A calls user B, an encapsulated ISUP/BICC CPG Generic 
notification 'call is a waiting call' is present in the 180 Ringing provisional 
response if the user B is NDUB. 


Configuration 


User B subscribed to the CW service 


SIP Parameter 


180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

CPG 

Event information 

Event indicator 
ALERTING 
Generic notification 

Notification indicator 
call is a waiting call 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

1 83 Session Progress (ACM) 

180 Ringing (CPG) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC CPG present in the 180 provisional response and the 

Generic notification is set to 'call is a waiting cal'? 
Repeat this test in reverse direction. 
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7.1 .5.1 1 Explicit Communication Transfer (ECT) 



Test case number 


SS ect 001 


Test case group 


SIP-SIP/Service/ECT 


Reference 


4.5.2/[11] 


SELECTION EXPRESSION 


[Network A] SE 37 AND [Network A] SE 1 1 AND [Network A] SE 49 


Test purpose 


Blind/assured transfer using the REFER method. 

User A is located in network A, user B and user C are located in network B. User 
A invokes ECT to transfer a session with user B to user C. 

• Ensure that a REFER request is sent from network A to network B in the 
dialogue with user B. The URI in the Refer-To header is set to the 
address of the ECT AS in network A and the method parameter is set to 
'INVITE'. 

• Ensure that an INVITE request is sent from network B to network A and 
the Request URI is set to the address of the ECT AS in network A. 

• Ensure that an INVITE request is sent from network A to network B and 
the Request URI is set to the address of user C. 


Configuration 




SIP Parameter 


REFER: Request URI address of user B 




Refer-To: <URI of ECT-AS>; method=invite 




INVITE 1 Request URI address of ECT-AS 








INVITE2: Request URI address of user C 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B 
A confirmed session is established between user A and user C 
User A invokes ECT to transfer the session to user C 
REFER 
202 Accepted 
NOTIFY (100) 
200 OK NOTIFY 


CASE Blind transfer 

BYE (A-B) 
200 OK BYE 




INVITE1 (ECT-AS) 
INVITE2 (user C) 
200 OK INVITE 

ACK 
200 OK INVITE 

ACK 
NOTIFY (200) 
200 OK NOTIFY 


CASE Assured transfer 

BYE (A-B) 
200 OK BYE 
Apply post test routine 
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Comments 



Check: Is a REFER request is sent network B, the Refer-To header is set to 

the URI of the ECT-AS in network A and a method parameter is 

present set to 'INVITE'? 
Check: Is a NOTIFY request sent to network A containing sipfrag body set to 

'SIP/2.0 100 Trying' and if Blind transfer is applicable the session from 

user A to user B is terminated by user A? 
Check: Is an INVITE request sent to network A the Request line is set to the 

address of the ECT-AS in network A? 
Check: Is an INVITE request is sent to network B the Request is set to the 

address of user C? 
Check: When the session from user B to user C is confirmed a NOTIFY 

request is sent to network A containing sipfrag body set to 'SIP/2.0 

200 OK' and if Assured transfer is applicable the session from user A 

to user B is terminated by user A? 
Check: Ensure the property of speech between user B and user C. 
Repeat this test in reverse direction. 
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Test case number 



SS ect 002 



Test case group 



SIP-SIP/Service/ECT 



Reference 



4.5.2/[11] 



SELECTION EXPRESSION 



[Network A] SE37 AND [Network A] SE 11 AND [Network A] SE 50 



Test purpose 



Consultative transfer using the REFER method. 

User A is located in network A, user B and user C are located in network B. User 
A invokes ECT to transfer a session with user B to user C. 

• Ensure that a REFER request is sent from network A to network B in the 
dialogue with user B. The URI in the Refer-To header is set to the 
address of the ECT AS in network A and the method parameter is set to 
'INVITE'. 

• Ensure that an INVITE request is sent from network B to network A and 
the Request URI is set to the address of the ECT AS in network A. 

• Ensure that an INVITE request is sent from network A to network B and 
the Request URI is set to the address of user C and a Replaces header 

is present containing the session identifiers of the session A - C. 



Configuration 



SIP Parameter 



REFER:Request URI address of user B 

Refer-To: <URI of ECT-AS>; method=invite 

INVITE 1 Request URI address of ECT-AS 

INVITE2: Request URI address of user C 
Require: replaces 

Replaces: <session A-C> 



Message flow 

SIP (Network A) 



Interconnection Interface 



SIP (Network B) 



A confirmed session is established between user A and user B 
A confirmed session is established between user A and user C 
User A invokes ECT to transfer the session to user C 





REFER 






202 Accepted 






NOTIFY (100) 






200 OK NOTIFY 






INVITE1 (ECT-AS) 






INVITE2 (user C) 






200 OK INVITE 






ACK 






200 OK INVITE 






ACK 






NOTIFY (200) 






200 OK NOTIFY 






BYE (A-B) 






200 OK BYE 






BYE (A-C) 






200 OK BYE 





Apply post test routine 



Comments 



Check: Is a REFER request is sent network B, the Refer-To header is set to 

the URI of the ECT-AS in network A and a method parameter is 

present set to 'INVITE'? 
Check: Is an INVITE request sent to network A the Request line is set to the 

address of the ECT-AS in network A? 
Check: Is an INVITE request is sent to network B the Request is set to the 

address of user C and a Replaces header is present contains the 

session identifiers of the session A-C? 
Check: Is the session A - B and the session A - C terminated? 
Check: Ensure the property of speech between user B and user C. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 003 


Test case group 


SIP-SIP/Service/ECT 


Reference 


4.5.2/[11], 4.7.2.9.7/[20] 


SELECTION EXPRESSION 


[Network A] SE37 AND NOT [Network A] SE 12 AND [Network A] SE 49 


Test purpose 


Blind/assured transfer using the 3pcc method. 

User A is located in network A, user B an user C are located in network B User A 
invokes ECT to transfer a session with user B to user C. 

• Ensure that the network A establishes a session to user C. 

• Ensure that the network A sends a relNVITE to update the session 
between user A and user B (SDP: IP address, port and codec). 


Configuration 




SIP Parameter 


INVITE 1 Request URI address of user C 

INVITE2: Request URI address of user B 
SDP 

c=IN IP4/6 [new IP address] 

m=audio [new port] RTP/AVP [new codec list] 

a=[new attributes] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B 
User A invokes ECT to transfer the session to user C 

INVITE1 (user C) 

180 Ringing 
200 OK INVITE 
ACK 




INVITE2 (user B) 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Check: Is an initial INVITE is sent from network A to user C to establish a 

dialogue between network A and user C? 
Check: Is a relNVITE is sent from network A to user B update the session 

parameter in the SDP? 
Repeat this test in reverse direction. 
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Test case number 


SS ect 004 


Test case group 


SIP-SIP/Service/ECT 


Reference 


4.5.2/[11], 4.7.2.9.7/[20] 


SELECTION EXPRESSION 


[Network A] SE37 AND [Network A] SE 12 AND [Network A] SE 50 


Test purpose 


Consultative transfer using the 3pcc method. 

User A is located in network A, user B and user C are located in network B 
User A invokes ECT to transfer a session with user B to user C. 

• Ensure that the network A sends a relNVITE to update the session 
between user A and user B (SDP: IP address, port and codec). 

• Ensure that the network A sends a relNVITE to update the session 
between user A and user C (SDP: IP address, port and codec). 


Configuration 




SIP Parameter 


INVITE 1 : Request URI address of user C 
SDP 

c=IN IP4/6 [new IP address] 

m=audio [new port] RTP/AVP [new codec list] 

a=[new attributes] 

INVITE2: Request URI address of user B 
SDP 

c=IN IP4/6 [new IP address] 

m=audio [new port] RTP/AVP [new codec list] 

a=[new attributes] 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B 
A confirmed session is established between user A and user C 
User A invokes ECT to transfer the session to user C 

INVITE1 (user B) 
200 OK INVITE 
ACK 




INVITE2 (user C) 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Check: Is a relNVITE is sent from network A to user B update the session 

parameter in the SDP. 
Check: Is a relNVITE is sent from network A to user C update the session 

parameter in the SDP. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 005 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in active state, call was previous on 
HOLD. 

BICC/ISUP - SIP-I interworking applies in the originating network User A and C 
are located in network A and user B is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User C in active state. 


Configuration 


User A is subscribed to the Explicit Call Transfer supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 
Content-Type: application/sdp 
a=sendrecv 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAC 

Generic Notification 

Call transfer active 
Call transfer number 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B and set on hold 
User A invokes ECT to transfer the session to user C 

INFO (LOP request) 

200 OK INFO 
INFO (LOP response) 
200 OK INFO 

CASE A 

INVITE (sendrecv; FAC) 
200 OK INVITE 
ACK 

CASE B 

INFO (FAC) 
200 OK INFO 
INVITE (sendrecv) 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


A session from User A to User B is already established 
User A sets the User B on hold 
User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to request ? 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to response'? 

Check: Is (CASE A) an INVITE request sent and an ISUP FAC message is 
present containing a Generic notification indicator is set to 'Call 
transfer active' and in addition the media stream is set to 
'sendrecv'? 

Check: Is (CASE B) an INFO request sent and an ISUP FAC message is 
present containing a Generic notification indicator is set to 'Call 
transfer active'? In addition is an INVITE request sent and the media 
stream is set to 'sendrecv' to resume the held session? 

NOTE: The content of the FAC in the INVITE request is Equal to the content 
of the FAC in the INFO request. 

Repeat this test in reverse direction. 
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Test case number 


SS ect 006 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in alerting state, call was previous on 
HOLD. 

BICC/ISUP - SIP-I interworking applies in the originating network User A and C 
are located in network A and user B is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User C in alerting state. 


Configuration 


User A is subscribed to the Explicit Call Transfer supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 

-[any boundary name] 
Content-Type: application/sdp 
a=sendrecv 

-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAC 

Generic Notification 

Call transfer alerting 
Call transfer number 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user B and set on hold 
User A invokes ECT to transfer the session to user C 

INFO (LOP request) 

200 OK INFO 
INFO (LOP response) 
200 OK INFO 

CASE A 

INVITE (sendrecv; FAC) 
200 OK INVITE 
ACK 

CASE B 

INFO (FAC) 
200 OK INFO 
INVITE (sendrecv) 
200 OK INVITE 
ACK 

Apply post test routine 


Comments 


A session from User A to User B is already established 
User A sets the User B on hold 
A session from User A to User C is already established 
User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to request ? 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to response'? 

Check: Is (CASE A) an INVITE request sent and an ISUP FAC message is 
present containing a Generic notification indicator is set to 'Call 
transfer alerting' and in addition the media stream is set to 'sendrecv'? 

Check: Is (CASE B) an INFO request sent and an ISUP FAC message is 
present containing a Generic notification indicator is set to 'Call 
transfer alerting'? In addition is an INVITE request sent and the media 
stream is set to 'sendrecv' to resume the held session? 

NOTE: The content of the FAC in the INVITE request is Equal to the content 
of the FAC in the INFO request. 

Repeat this test in reverse direction. 
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Test case number 


SS ect 007 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in active state. 

BICC/ISUP - SIP-I interworking applies in the originating network Users A and B 
are located in network A and User C is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User C in active state. 


Configuration 


User A is subscribed to the Explicit Call Transfer supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAC 

Generic Notification 

Call transfer active 
Call transfer number 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A confirmed session is established between user A and user C 
User A invokes ECT to transfer the session to user C 

INFO (LOP request) 

200 OK INFO 
INFO (LOP response) 

200 OK INFO 




INFO (FAC) 
200 OK INFO 
Apply post test routine 


Comments 


A session from User A to User B is already established 
User A sets the User B on hold 
A session from User A to User C is already established 
User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to request ? 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to response ? 

Check: Is (CASE B) an INFO request sent and an ISUP FAC message is 
present containing a Generic notification indicator is set to 'Call 
transfer active'? 

NOTE: The content of the FAC in the INVITE request is Equal to the content 

of the FAC in the INFO request. 
Repeat this test in reverse direction. 
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Test case number 


SS ect 008 I 


Test case group 


SIP-SIP/Service/ECT 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 60 


Test purpose 


SIP-I support. Call Transfer invoked in alerting state. 

BICC/ISUP - SIP-I interworking applies in the originating network User A and B 
are located in network A and user C is located in network B. 
Ensure that an User A can successfully invoke the ECT supplementary service 
and transfer the call with User B to User C in alerting state. 


Configuration 


User A is subscribed to the Explicit Call Transfer supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
CPG 

Generic Notification 

Call transfer alerting 
Call transfer number 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A session in the early dialogue is established between user A and user C 
User A invokes ECT to transfer the session to user C 

INFO (LOP request) 

200 OK INFO 
INFO (LOP response) 

200 OK INFO 




INFO (CPG) 
200 OK INFO 
Apply post test routine 


Comments 


A session from User A to User B is already established 
User A sets the User B on hold 
A session from User A to User C is already established 
User A invokes the ECT service 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to request ? 

Check: Is (optional) an INFO request is sent from Network A to Network B 
and an ISUP LOP message is present the Loop prevention indicator 
set to response ? 

Check: Is (CASE B) an INFO request sent and an ISUP CPG message is 
present containing a Generic notification indicator is set to 'Call 
transfer alerting'? 

NOTE: The content of the FAC in the INVITE request is Equal to the content 

of the FAC in the INFO request. 
Repeat this test in reverse direction. 
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7.1.5.12 Malicious Communication Identification (MCID) 



Test case number 


SS mcid 001 ! 


Test case group 


SIP-SIP/Service/MCID 


Reference 


4.5.2.5/[18] 


SELECTION EXPRESSION 


SE38 


Test purpose 


Network B sends a MCID request, no response. 

User A is located in network A, user B is located in network B and subscribed to 
the Malicious Communication Identification service. 

When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network A requesting the 
originating identity. After timeout of timer TO-ID the network B sends the 180 
Ringing response. 


Configuration 


User B is subscribed to the MCID service 


SIP Parameter 


INFO: 

<...:mcid > 

<...:request> 

<. . . :McidRequestlndicator>01 </. . . :McidRequestlndicator> 
<. . . :Holdinglndicator >...</... :Holdinglndicator> 
</...:request> 
</...:mcid> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
INFO 
200 OK INFO 
Timeout To-id 
180 Ringing 
Apply post test routine 


Comments 


Check: Is an INFO request sent to network A? 
Check: Is the McidRequestlndicator element set to ,01 '? 
Check: is a 200 OK INFO response sent to network B? 
Repeat this test in reverse direction. 
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Test case number 


SS mcid 002 


Test case group 


SIP-SIP/Service/MCID 


Reference 


4.5.2.5/[18] 


SELECTION EXPRESSION 


SE 38 AND SE 47 


Test purpose 


Network B sends a MCID request, MCID response. 

PSTN user A is located in network A, user B is located in network B and 
subscribed to the Malicious Communication Identification service. 
When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network B requesting the 
originating identity. After receipt of an INFO request from network A the network 
B sends the 180 Ringing response. 


Configuration 


User B subscribed to the MCID service 

User A is a ISDN or POTS user in the PSTN of network A 


SIP Parameter 


INFO: 

<...:mcid > 

<...:request> 

<. . . :McidRequestlndicator>01 </. . . :McidRequestlndicator> 
<. . . :Holdinglndicator >. . .</. . . :Holdinglndicator> 
</...:request> 
</...:mcid> 

<...:mcid > 

<...:response> 

<. . . :McidResponselndicator>01 </. . . :McidResponselndicator> 
<. . . :HoldingProvidedlndicator>. . .</. . . :HoldingProvidedlndicator> 
<. . . :OrigPartyldentity>any URI</. . . :OrigPartyldentity> 
<. . . :OrigPartyPresentationRestriction> 
true/false 

</. . . :OrigPartyPresentationRestriction> 
</...:response> 
</...:mcid> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
INFO 
200 OK INFO 

INFO 
200 OK INFO 
180 Ringing 
Apply post test routine 


Comments 


Check: Is an INFO request sent to network A? 

Check: Is the McidRequestlndicator element set to ,01 '? 

Check: Is a 200 OK INFO response sent to network B? 

Check: Is an INFO request sent to network B? 

Check: Is the McidResponselndicator element set to ,01 '? 

Check: Is the OrigPartyldentity element present in the response element? 

Check: Is a 200 OK INFO response sent to network A? 

A INFO request containing a mcid response element sent by the MGCF in 

network A is optional. 

Repeat this test in reverse direction. 
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Test case number 


SS mcid 003 


Test case group 


SIP-SIP/Service/MCID 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 61 


Test purpose 


SIP-I support. Network B sends a MCID request, no response. 

User A is located in network A, user B is located in the PSTN/PLMN part of 
network B and subscribed to the Malicious Call Identification service. 
When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network A and an ISUP/BICC 
IDR message is present the MCID request indicator is set to 'MCID requested' 
requesting the originating identity. After timeout of timer (ISUP) T39 the network 
B sends the 180 Ringing response. 


Configuration 


User B is subscribed to the MCID service 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IDR 

MCID request indicators 

MCID request indicator 
MCID requested 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
INFO(IDR) 
200 OK INFO 
Timeout To-id 
180 Ringing 
Apply post test routine 


Comments 


Check: Is an INFO request sent to network A? 

Check: Is a ISUP/BICC IDR message is present and the MCID request 

indicator is set to 'MCID requested'? 
Check: Is a 200 OK INFO response sent to network B? 
NOTE: Based on network policies the MCID request indicator can be set 

to'MCID not requested'. 
Repeat this test in reverse direction. 
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Test case number 


SS mcid 004 


Test case group 


SIP-SIP/Service/MCID 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 AND SE 61 


Test purpose 


SIP-I support. Network B sends a MCID request, MCID response. 

PSTN user A is located in network A, user B is located in the PSTN/PLMN part 
of network B and SIP-I - ISUP/BICC interworking applies and User B is 
subscribed to the Malicious Call Identification service. 

When user A call user B and no originating identification is present in the INVITE 
request, the network B sends an INFO request to network B requesting the 
originating identity. After receipt of an INFO request from network A the network 
B sends the 180 Ringing response. 


Configuration 


User B subscribed to the MCID service 

User A is a ISDN or POTS user in the PSTN of network A 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IDR 

MCID request indicators 

MCID request indicator 
MCID requested 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IRS 

MCID response indicators 

MCID response indicator 
MCID included 
Calling party number 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
INFO(IDR) 
200 OK INFO 

INFO(IRS) * 
200 OK INFO 
180 Ringing 
Apply post test routine 


Comments 


Check: Is an INFO request sent to network A and a ISUP/BICC IDR is present 
and the MCID request indicator is set to 'MCID requested'? 

Check: Is a 200 OK INFO response sent to network B? 

Check: Is an INFO request sent to network B and a ISUP/BICC IRS is present 
and the MCID response indicator is set to 'MCID included'? 

Check: Is the Calling party number present in the attached ISUP/BICC IRS? 

Check: Is a 200 OK INFO response sent to network A? 

Repeat this test in reverse direction. 
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7.1 .5.13 Message Waiting Indication (MWI) 



Test case number 


SS_mwi_001 ! 


Test case group 


SIP-SIP/Service/MWI 


Reference 


4.7.2/[16] 


SELECTION EXPRESSION 


[Network A] SE 39 AND [Network B] SE 39 


Test purpose 


Initial subscription of a Voicemail box. 

The Voicemail owner is in network A, his Voicemail box is located in network B. 
Ensure that a Voicemail owner is able to activate his Voicemail box. 


Configuration 


Voicemail in network B 
Voicemail owner in network A 


SIP Parameter 


SUBCRIBE 

Event: message-summary 
Expires: [any value] 

Accept: application/simple-message-summary 

NOTIFY 

Subscription-State: active;expires=[any value] 
Event: message-summary 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

SUBCRIBE 

200 OK SUBSCRIBE 

NOTIFY 

200 OK NOTIFY 
200 OK BYE 

NOTIFY 

200 OK NOTIFY 

Apply post test routine 


Comments 


Check: Is it possible for a user in network A to subscribe to a Voicemail box in 
network B? 

Check: Is the Event header in the SUBCRIBE set to 'message-summary'? 
Check: Is the Accept header in the SUBCRIBE set to 'application/simple- 
message-summary'? 
Check: Is the Event header in the NOTIFY is set to 'message-summary'? 
Repeat this test in reverse direction. 
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Test case number 


SS mwi 002 I 


Test case group 


SIP-SIP/Service/MWI 


Reference 


4.7.2/[16] 


SELECTION EXPRESSION 


[Network A] SE 39 AND [Network B] SE 39 ! 


Test purpose 


A new entry in the Voicemail box is indicated to the owner. 

The Voicemail owner is in network A, his Voicemail box is located in network B. 
Ensure when a user calls user A and the call is not answered, the call is 
forwarded to the Voicemail box of user A in network B. Ensure that the user A is 
notified by message waiting indication that there is a new message present in his 
voicemail account. 


Configuration 


Voicemail in network B 
Voicemail owner in network A 


SIP Parameter 


NOTIFY 

Subscription-State: active;expires=[any value] 
Event: message-summary 

Content-Type: application/simple-message-summary 
Messages-Waiting: yes 

Message-Account: sip:userA@networkA (optional) 
Voice-Message: [any new value]/[any old value] (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 

200 OK INVITE 
ACK 

BYE 

200 OK BYE 
NOTIFY 

200 OK NOTIFY 

Apply post test routine 


Comments 


Check: Is the Event header in the NOTIFY set to 'message-summary'? 
Check: Is the Content-Type header in the NOTIFY set to 'application/simple- 
message-summary'? 
Check: Contains the MIME body the header 'Messages-Waiting' set to 'yes'? 
Check: Contains the MIME body the optional header 'Message-Account'? 
Check: Contains the MIME body the optional header 'Voice-Message'? 
Repeat this test in reverse direction. 



ETSI 



204 



ETSI TS 101 585 V1.1.1 (2012-08) 



7.1 .5.14 Completion of Communications to Busy Subscriber (CCBS), Completion of 
Communications by No Reply (CCNR) 



Test case number 


SS cc 001 


Test case group 


SIP-SIP/Service/CC ! 


Reference 


4.5.4.3/[14] 


SELECTION EXPRESSION 


[Network A] SE 40 AND [Network B] SE 40 I 


Test purpose 


Indicating of CCBS possible. 

User A is located in network A and user B is located in network B. 

Ensure when user A calls user B and user B is busy, the network B sends an 

indication that CCBS is possible in the 486 Busy Here final response. 


Configuration 




SIP Parameter 


486: 

Call-Info: <sip:UE-B>;purpose=call-completion;m=BS 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
486 Busy Here 
ACK 


Comments 


Check: The 486 final response contains the Call-Info header. 
Check: The Call-Info header contains the URI of user B as the monitor point in 
network B. 

Check: The Call-Info header contains the purpose parameter set to 

'call-completion' and the m parameter set to 'BS'. 
Repeat this test in reverse direction. 




Test case number 


SS cc 002 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.3/[14] 


SELECTION EXPRESSION 


[Network A] SE 41 AND [Network B] SE 41 


Test purpose 


Indicating of CCNR possible. 

User A is located in network A and user B is located in network B. 

Ensure when user A calls user B and user B is free, the network B sends an 

indication that CCNR is possible in the 180 Ringing provisional response. 


Configuration 




SIP Parameter 


180: 

Call-Info: <sip:UE-B>;purpose=call-completion;m=NR 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
Apply post test routine 


Comments 


Check: The 180 provisional response contains the Call-Info header. 
Check: The Call-Info header contains the URI of user B as the monitor point in 
network B. 

Check: The Call-Info header contains the purpose parameter set to 

'call-completion' and the m parameter set to 'NR'. 
Repeat this test in reverse direction. 
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Test case number 


SS cc 003 I 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.2/[14] | 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B] SE41) 


Test purpose 


Invocation of CCBS or CCNR. 




User A is located in network A and user B is located in network B. 

• Ensure when user A call user B and user B is busy, the indication that 
CCBS is possible is sent to the network A. when user A invokes CCBS, 
a SUBSCRIBE request is sent to the network B, the Event header is set 
to 'call-completion' and the m parameter in the Request line is set to 
'BS\ 

• Ensure when user A call user B and user B is free, the indication that 
CCNR is possible is sent to the network A. when user A invokes CCNR, 
a SUBSCRIBE request is sent to the network B, the Event header is set 
to 'call-completion' and the m parameter in the Request line is set to 
'NR'. 

Ensure that the network B sends a NOTIFY request to network A to confirm that 
the request is in the Call completion queue at the terminating Application Server. 






Configuration 




SIP Parameter 


SUBSRIBE sip:B-AS;m=BS or m=NR 
From:<UE-A> 
To:<UE-B> 
Contact:<A-AS> 
Event:call-completion 

NOTIFY sip:A-AS 

Event:call-completion 

Content-Type: application/call-completion 

state: queued 

service-retention 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
An indication whether CCBS or CCNR is possible is sent by network B 

SUBSCRIBE 
202 Accepted 




NOTIFY 
200 OK NOTIFY 
Apply post test routine 


Comments 


Check: Is a SUBCRIBE request is sent to network B? 

Check: Is the m parameter in the Request URI is set to 'BS' in case of CCBS 

request or set to 'NR' in case of CCNR? 
Check: Is a NOTIFY request is sent to network A and the Event header is set 

to 'call-completion' and the state header in the message body is set to 

'queued". 
Repeat this test in reverse direction. 

NOTE: The service-retention header in the NOTIFY body is a network option. 
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Test case number 


SS cc 004 I 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.3/[14] I 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B] SE41) 


Test purpose 


Invocation of CCBS or CCNR unsuccessful; short term denial 

User A is located in network A and user B is located in network B. 

Ensure that user A invokes a CCBS or CCNR request to network B and the 
network B is currently unable to process the request (e.g. the B-queue is full), a 
480 Temporarily Unavailable final response is sent. 


Configuration 




SIP Parameter 


SUBSRIBE sip:B-AS;m=BS or m=NR 
From:<UE-A> 
To:<UE-B> 
Contact:<A-AS> 
Event:call-completion 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
An indication whether CCBS or CCNR is possible is sent by network B 

SUBSCRIBE 
480 (Temporarily Unavailable) 


Comments 


Check: Is a SUBCRIBE request is sent to network B? 

Check: Is the m parameter in the Request URI is set to 'BS' in case of CCBS 

request or set to 'NR' in case of CCNR? 
Check: Is a 480 Temporarily Unavailable sent from network B indicates the 

CCBS or CCNR request is unsuccessful e.g. CC queue is full? 
Repeat this test in reverse direction. 
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Test case number 


SS cc 005 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.3/[14] 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B] SE41) 


Test purpose 


Successful CC operation 

User A is located in network A and user B is located in network B. User A has 

r it it A Ann AAk in j. 

successfully invoked a CCBS or CCNR request. 

• Ensure when the user B becomes available for CC recall, the CC recall 
procedure is started. The network B sends a NOTIFY request to network A 
and a state header is present in the message body set to 'ready'. 

• Ensure that the recall from user A to user B is successful. 

• Ensure that a CC revocation notification is dent to network A to indicate the 
subscription is terminated; the reason header is set to 'noresource'. 


Configuration 




SIP Parameter 


NOTIFY sip:0-AS 

Event:call-completion 
Content-Type: application/call-completion 
state: ready 

NOTIFY sip:0-AS 

Event:call-completion 

Subscription-State: terminated; reason=noresource 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A CCBS or CCNR request was already successful 

NOTIFY 
200 OK NOTIFY 




INVITE 
180 Ringing 




NOTIFY 
200 OK NOTIFY 




200 OK INVITE 
ACK 

Apply post test routine 


Comments 


Check: Is a NOTIFY request is sent to network A and the Event header is set 
to 'call-completion' and the state header in the message body is set to 
'ready'? 

Check: Is the recall from user A to user B is successful? 

Check: Is the CC revocation is performed after the 1 80 Ringing or the 200 OK 

INVITE was sent to user A? 
Repeat this test in reverse direction. 
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Test case number 


SS cc 006 I 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.31/[14] 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B] SE41) 


Test purpose 


No CC call as result. 

User A is located in network A and user B is located in network B. User A has 
successfully invoked a CCBS or CCNR request. 

Ensure when no recall result is performed while CC-T9 is running (user A does 
not calls to user B) the network B sends a NOTIFY request to network A with an 
indication that the subscription is terminated, the reason header is set to 
'rejected'. 


Configuration 




SIP Parameter 


NOTIFY sip:0-AS 

Event:call-completion 
Content-Type: application/call-completion 
state: ready 

NOTIFY sip:0-AS 

Event:call-completion 

Subscription-State: terminated; reason=rejected 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A CCBS or CCNR request was already successful 
User B is available for recall 

NOTIFY 
200 OK NOTIFY 
CC-T9 expires 

NOTIFY 
200 OK NOTIFY 


Comments 


Check: Is a NOTIFY request is sent to network A and the Event header is set 
to 'call-completion' and the state header in the message body is set to 
'ready'? 

User A does not perform the recall 

Check: Is the CC revocation is performed after timer CC-T9 expires? 
Repeat this test in reverse direction. 
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Test case number 


SS cc 007 


Test case group 


SIP-SIP/Service/CC 


Reference 


4.5.4.2/[14] 


SELECTION EXPRESSION 


([Network A] SE 40 OR [Network A] SE 41) AND ([Network B] SE 40 OR 
[Network B] SE41) 


Test purpose 


User A is unavailable while CC recall is performed. 

User A is located in network A and user B is located in network B. User A has 
successfully invoked a CCBS or CCNR request. User B is available for CC-recall 
and network B sends a CC-recall notification to network A. 

• Ensure that network A sends PUBLISH request to suspend the recall 
procedure. 

• Ensure that network A sends PUBLISH request to resume the recall 
procedure if user A is available to complete the recall procedure. 

• Ensure the network B sends a NOTIFY request to indicate the CC-recall 
procedure. 


Configuration 




SIP Parameter 


NOTIFY sip:0-AS 

EvenLcall-completion 
Content-Type: application/call-completion 
state: ready 

PUBLISH sip B-AS 
To: SIP 2 
Event: presence 

Content-Type: application/pidf+xml 
<?xml version="1 .0" encoding="UTF-8"?> 
<presence 
<status> 
<basic>closed</basic> 

PUBLISH sip B-AS 
To: SIP 2 
Event: presence 

Content-Type: application/pidf+xml 
<?xml version="1 .0" encoding="UTF-8"?> 
<presence 
<status> 
<basic>open</basic> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 
A CCBS or CCNR request was already successful 
User B is available for recall 

NOTIFY 
200 OK NOTIFY 
User A is busy 

PUBLISH 
200 OK PUBLISH 
User A is no longer busy 
PUBLISH 
200 OK PUBLISH 
User B is available for recall 
NOTIFY 
200 OK NOTIFY 
Apply post test routine 


Comments 
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Test case number 


SS cc 008 


Test case group 


SIP-SIP/Service/CC 


Reference 


6.11.2/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support: Indicating of CCBS possible. 

BICC/ISUP - SIP-I interworking applies in the terminating network and User A is 
located in network A and user B is located in network B. 
Ensure when user A calls user B and user B is busy, the network B sends a 486 
Busy Here final response and an encapsulated ISUP REL is present, the Cause 
value indicator is set to #17 or #34 and the CCBS possible indicator is set to 
'CCBS possible'. 


Configuration 




SIP Parameter 


486: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

REL 

Cause value 

#17 or #34 
Diagnostics 

CCBS possible 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
486 Busy Here (REL) 
ACK 


Comments 


Check: The 486 final response contains an encapsulated BICC/ISUP REL, the 
Cause value set to 1 7 or 34 and the Diagnostics set to 'CCBS 
possible'. 

Repeat this test in reverse direction. 




Test case number 


SS cc 009 


Test case group 


SIP-SIP/Service/CC 


Reference 


6.5/[24] 


SELECTION EXPRESSION 


[Network B] SE 17 AND SE 47 


Test purpose 


SIP-I support: Indicating of CCNR possible. 

BICC/ISUP - SIP-I interworking applies in the terminating network User A is 
located in network A and user B is located in network B. 
Ensure when user A calls user B and user B is free, the network B sends a 1 80 
Ringing provisional response and an encapsulated ACM is present containing a 
CCNR possible indicator set to 'CCNR possible'. 


Configuration 




SIP Parameter 


180: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ACM 

CCNR possible indicator 
CCNR possible 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: The 180 provisional response contains an encapsulated ACM. 
Check: The CCNR possible indicator in the ACM is set to 'CCNR possible'. 
Repeat this test in reverse direction. 
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7.1 .6 Other PSTN services (SIP-I interworking) 



7.1 .6.1 User-to-User Signaling (UUS) 



Test case number 


SS_uus_001 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 implicit in initial INVITE 
request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 implicit request 
calls user B an User-to-user Information parameter is present in the 
encapsulated IAM of the initial INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 1 implicit request I 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC IAM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 002 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 implicit response in 180. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 implicit request 
calls user B subscribed to User-to-User service 1 an User-to-user Information 
parameter is present in the encapsulated ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 1 implicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Information 
User Information 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 
ISUP/BICC IAM? 

Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 003 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 explicit in initial INVITE 
request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B an User-to-user Indicator parameter is present set to 'Request 
service 1', 'not essential' or 'essential' in the encapsulated IAM of the initial 
INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

IAM 

User-to-user Indicator 
Request 
service 1 

not essential or essential 
User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 
ISUP/BICC IAM? 

Check: Is the Request service 1 set to 'not essential' or 'essential'? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 004 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 explicit response in 180. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B subscribed to User-to-User service 1 an User-to-user Indicator 
parameter is present set to 'Response', 'service 1 provided' in the encapsulated 
ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 1 

essential or not essential 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 
service 1 provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 
ISUP/BICC IAM? 

Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 1 provided' in the encapsulated ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 005 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 not essential explicit 
rejected in 180. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B not subscribed to User-to-User service 1 the call is rejected by the 
network an User-to-user Indicator parameter is present set to 'Response', 
'service 1 not provided' in the encapsulated ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 
User B is not subscribed to the User-to-User service 1 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 1 
not essential 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 

service 1 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 
ISUP/BICC IAM? 

Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 1 not provided' in the encapsulated ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 006 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


6.11.2, 7.1 /[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 1 essential explicit 
rejection. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 1 explicit request 
calls user B subscribed to User-to-User service 1 essential is rejected by the 
network or by the user. A 500 Server Internal Error is sent and an encapsulated 
ISUP/BICC REL is present, the Cause value is set to #29 or #69. 


Configuration 


User A is subscribed to the User-to-User service 1 explicit request 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 1 
essential 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Cause value 
#29 or #69 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
500 Server Internal Error (REL) 
ACK 

Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC IAM set to 'Request', 'service 1\ 'essential'? 
Check: Is an ISUP/BICC REL encapsulated in the 500 response? 
Check: Is the Cause value set to #29 or #69 in the encapsulated REL? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 007 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 in initial INVITE request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 2', 'not 
essential' or 'essential' in the encapsulated IAM of the initial INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 2 

not essential or 'essential' 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request and 
the a User-to-user Indicator parameter is set to Is the Request 
service 2 'not essential' or 'essential'? 

Repeat this test in reverse direction. 
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Test case number 


SS uus 008 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1 /[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 in initial INVITE request 
successful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 2', 'not 
essential' or 'essential' in the encapsulated IAM of the initial INVTE request. The 
User-to-User service is successful. 


Configuration 


User A is subscribed to the User-to-User service 2 
User B is subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Contpnt-Tvnp" annlination/i < ?uD'VPr < ?ion=itu-t < 52 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 2 

not essential or 'essential' 




180 


Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 
service 2 provided 




INFO 


Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 




183 


Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) 




Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
INFO (USR) 
200 OK INFO 
183 Session Progress (USR) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request and 

the a User-to-user Indicator parameter is set to Is the Request 

service 2 'not essential' or 'essential'? 
Check: Is an ISUP/BICC ACM encapsulated in the 180 and the User-to-user 

Indicator parameter is set to 'Response', 'service 2 provided'? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network A to network B containing an User-to-user Information 

parameter? 

Check: Is an ISUP/BICC USR encapsulated in the 183 response sent from 
network B to network A containing an User-to-user Information 
parameter? 

Repeat this test in reverse direction. 
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Test case number 


SS uus 009 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 not essential rejected in 
180 response. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 not essential calls 
user B not subscribed to User-to-User service 2 the call is rejected by the 
network an User-to-user Indicator parameter is present set to 'Response', 
'service 2 not provided' in the encapsulated ACM of the 180 response. 


Configuration 


User A is subscribed to the User-to-User service 2 
User B is not subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 2 
not essential 

180 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ACM 

User-to-user Indicator 
Response 

service 2 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC IAM set to 'Request', 'service 2' 'not essential'? 
Check: Is an ISUP/BICC ACM encapsulated in the 1 80 response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 2 not provided' in the encapsulated ISUP/BICC ACM? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 010 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


6.11.2, 7.1 /[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 2 essential rejection. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 2 essential calls 
user B not subscribed to User-to-User service 2 the call is rejected by the 
network. A 500 Server Internal Error is sent and an encapsulated ISUP/BICC 
REL is present, the Cause value is set to #29 or #69. 


Configuration 


User A is subscribed to the User-to-User service 2 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 2 
essential 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Cause value 
#29 or #69 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
500 Server Internal Error (REL) 
ACK 

Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC IAM set to 'Request', 'service 1\ 'essential'? 
Check: Is an ISUP/BICC REL encapsulated in the 500 response? 
Check: Is the Cause value set to #29 or #69 in the encapsulated REL? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 011 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 in initial INVITE request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 3', 'not 
essential' or 'essential' in the encapsulated IAM of the initial INVTE request. 


Configuration 


User A is subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 3 

not essential or 'essential' 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request and 
the a User-to-user Indicator parameter is set to Is the Request 
service 3 'not essential' or 'essential'? 

Repeat this test in reverse direction. 
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Test case number 


SS uus 012 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1 /[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 in initial INVITE request 
successful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 calls user B an 
User-to-user Indicator parameter is present set to 'Request service 3', 'not 
essential' or 'essential' in the encapsulated IAM of the initial INVTE request. The 
User-to-User service is successful. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 3 

not essential or 'essential' 

200 OK 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ANM 

User-to-user Indicator 
Response 
service 3 provided 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
200 OK INVITE (ANM) 
ACK 
INFO (USR) 
200 OK INFO 
INFO (USR) 
200 OK INFO 
Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request and 
the 

a User-to-user Indicator parameter is set to Is the Request service 3 
'not essential' or 'essential'? 
Check: Is an ISUP/BICC ANM encapsulated in the 200 OK INVITE and the 
User-to-user Indicator parameter is set to 'Response', 'service 3 
provided'? 

Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 
network A to network B containing an User-to-user Information 
parameter? 

Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 
network B to network A containing an User-to-user Information 
parameter? 

Repeat this test in reverse direction. 
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Test case number 


SS uus 013 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


7.1,6.5/[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 not essential rejected in 
200 OK response. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 not essential calls 
user B not subscribed to User-to-User service 3 the call is rejected by the 
network an User-to-user Indicator parameter is present set to 'Response', 
'service 3 not provided' in the encapsulated ANM of the 200 OK final response. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is not subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 3 
not essential 

200 OK 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
ANM 

User-to-user Indicator 
Response 

service 3 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
180 Ringing (ACM) 
200 OK INVITE (ANM) 
ACK 

Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Information parameter present in the encapsulated 

ISUP/BICC IAM set to 'Request', 'service 3' 'not essential'? 
Check: Is an ISUP/BICC ANM encapsulated in the 200 OK response? 
Check: Is an User-to-user Indicator parameter present set to 'Response', 

'service 3 not provided' in the encapsulated ISUP/BICC ANM? 
Repeat this test in reverse direction. 



ETSI 



224 



ETSI TS 101 585 V1.1.1 (2012-08) 



Test case number 


SS uus 014 I 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


6.11.2, 7.1 /[24] I 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 essential rejection. 

BICC/ISUP - SIP-I interworking applies in the originating and terminating network 
User A is located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 essential calls 
user B not subscribed to User-to-User service 3 the call is rejected by the 
network. A 500 Server Internal Error is sent and an encapsulated ISUP/BICC 
REL is present, the Cause value is set to #29 or #69. 


Configuration 


User A is subscribed to the User-to-User service 3 


SIP Parameter 


INVITE: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

User-to-user Indicator 
Request 
service 3 
essential 

500 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Cause value 
#29 or #69 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE (IAM) 
500 Server Internal Error (REL) 
ACK 

Apply post test routine 


Comments 


Check: Is an ISUP/BICC IAM encapsulated in the initial INVITE request? 
Check: Is a User-to-user Indicator parameter present in the encapsulated 

ISUP/BICC IAM set to 'Request', 'service 1', 'essential'? 
Check: Is an ISUP/BICC REL encapsulated in the 500 response? 
Check: Is the Cause value set to #29 or #69 in the encapsulated REL? 
Repeat this test in reverse direction. 
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Test case number 


SS uus 015 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1 /[24] 


SELECTION EXPRESSION 


([Network A] SE 1 7 AND SE 47) AND ([Network B] SE 1 7 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 during a session is 
established successful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 user A is able to 
request the User-to-User service 3 while the session is established. The User-to- 
User service is successful. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is subscribed to the User-to-User service 3 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAR 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Request 
service 3 
not essential 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAA 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Response 
service 3 provided 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
USR 

User-to-user Information 
User Information 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A session is already established 

INFO (FAR) 
200 OK INFO 

INFO (FAA) 
200 OK INFO 

INFO (USR) 
200 OK INFO 

INFO (USR) 
200 OK INFO 
Apply post test routine 
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Comments 



A session is already established 

Check: Is an ISUP/BICC FAR encapsulated in the INFO request sent from 

Network A to Network B and the a User-to-user Indicator parameter is 

set to Is the Request service 3 'not essential'? 
Check: Is an ISUP/BICC FAA encapsulated in the INFO request sent from 

Network B to Network A and the User-to-user Indicator parameter is 

set to 'Response', 'service 3 provided'? 
Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 

network A to network B containing an User-to-user Information 

parameter? 

Check: Is an ISUP/BICC USR encapsulated in the INFO message sent from 
network B to network A containing an User-to-user Information 
parameter? 

Repeat this test in reverse direction. 



Test case number 


SS uus 016 


Test case group 


SIP-SIP/SIP-I/UUS 


Reference 


5.4.3.2, 6.5, 7.1 /[24] 


SELECTION EXPRESSION 


([Network A] SE 17 AND SE 47) AND ([Network B] SE 17 AND SE 47) AND SE 
63 


Test purpose 


SIP-I support: Indicating of User-to-User service 3 during a session is 
established unsuccessful. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. 
Ensure when user A subscribed to the User-to-User service 3 user A is able to 
request the User-to-User service 3 while the session is established. The service 
request is rejected by Network B. 


Configuration 


User A is subscribed to the User-to-User service 3 
User B is not subscribed to the User-to-User service 3 


SIP Parameter 


INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FAR 

Facility indicator 

user-to-user service 
User-to-user Indicator 
Request 
service 3 
not essential 

INFO: 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
FRJ 

Facility indicator 

user-to-user service 
User-to-user Indicator 

Response 

service 3 not provided 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A session is already established 

INFO (FAR) 
200 OK INFO 
INFO (FRJ) 
200 OK INFO 
Apply post test routine 


Comments 


A session is already established 

Check: Is an ISUP/BICC FAR encapsulated in the INFO request sent from 

Network A to Network B and the a User-to-user Indicator parameter is 

set to Is the Request service 3 'not essential'? 
Check: Is an ISUP/BICC FAA encapsulated in the INFO request sent from 

Network B to Network A and the User-to-user Indicator parameter is 

set to 'Response', 'service 3 not provided'? 
Repeat this test in reverse direction. 
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7.1 .6.2 Subaddressing (SUB) 



Test case number 


SS sub 001 I 


Test case group 


SIP-SIP/SIP-I/SUB 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 62 


Test purpose 


SIP-I support: Calling party subaddress can be correctly transferred in the 
Access Transport parameters. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. Ensure that an 
ISUP/BICC ATP parameter present in the encapsulated IAM of the INVITE 
request and contains a Calling party subaddress. 


Configuration 


User A is subscribed to the SUB supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

Access transport 

Calling party subaddress 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 


Comments 


Establish a call from User A subscribed to the SUB supplementary service to 
user B 

Check: Is an ISUP/BICC IAM present in the initial INVITE request? 
Check: Is an ISUP/BICC ATP parameter present in the encapsulated IAM 

containing a Calling party subaddress? 
Repeat this test in reverse direction. 




Test case number 


SS sub 002 


Test case group 


SIP-SIP/SIP-I/SUB ! 


Reference 


7.1/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 62 


Test purpose 


SIP-I support. Called party subaddress can be correctly transferred in the 
Access Transport parameters. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. Ensure that an 
ISUP/BICC ATP parameter present in the encapsulated IAM of the INVITE 
request and contains a Called party subaddress. 


Configuration 


User A is subscribed to the SUB supplementary service 


SIP Parameter 


INVITE 

Content-Type: multipart/mixed;boundary=[any boundary name] 
-[any boundary name] 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
IAM 

Access transport 

Called party subaddress 
-[any boundary name]- 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 
response? 

Check: Is an ISUP/BICC ATP parameter present in the encapsulated ANM 

containing a Called party subaddress? 
Repeat this test in reverse direction. 
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Test case number 


SS sub 003 


Test case group 


SIP-SIP/SIP-I/SUB 


Reference 


6.7/[24] 


SELECTION EXPRESSION 


[Network B] SE 1 7 AND SE 47 AND SE 62 


Test purpose 


SIP-I support. Connected party subaddress can be correctly transferred in 
the Access Transport parameters. 

BICC/ISUP - SIP-I interworking applies in the terminating network User A is 
located in network A and user B is located in network B. Ensure that an 
ISUP/BICC ATP parameter present in the encapsulated ANM of the 200 OK 
INVITE final response and a Connected party subaddress is contained. 


Configuration 


User B is subscribed to the SUB supplementary service 


SIP Parameter 


200 OK INVITE 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 

ANM 

Access transport 

Connected party subaddress 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE(IAM) 
180 Ringing(ACM) 
200 OK INVITE(ANM) 
ACK 

Apply post test routine 


Comments 


Check: Is the BICC/ISUP ANM encapsulated in the 200 OK INVITE final 
response? 

Check: Is an ISUP/BICC ATP parameter present in the encapsulated ANM 

containing a Called party subaddress? 
Repeat this test in reverse direction. 
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7.1 .6.3 Terminal Portability (TP) 



Test case number 


SS tp 001 


Test case group 


SIP-SIP/SIP-I/TP 


Reference 


5.4.3.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 64 


Test purpose 


SIP-I support. SUS and RES messages transferred in an INFO request. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. A session is already 
established. Ensure that an INFO request is sent from Network A to Network B 
and an ISUP SUS message is encapsulated containing a Suspend/resume 
indicator set to ISDN subscriber initiated. Ensure that an INFO request is sent 
from Network A to Network B and an ISUP RES message is encapsulated 
containing a Suspend/resume indicator set to ISDN subscriber initiated. 


Configuration 


User A is subscribed to the Terminal Portability supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
SUS 

Suspend/resume indicator 
ISDN subscriber initiated 

INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
RES 

Suspend/resume indicator 
ISDN subscriber initiated 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
INFO(SUS) 
200 OK INFO 

INFO(RES) 
200 OK INFO 
Apply post test routine 


Comments 


A session is already established 

Check: Is an ISUP SUS message encapsulated in the INFO request and the 
Suspend/resume indicator set to ISDN subscriber initiated'? 

Check: Is an ISUP RES message encapsulated in the INFO request and the 
Suspend/resume indicator set to 'ISDN subscriber initiated'? 

Repeat this test in reverse direction. 
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Test case number 


SS tp 002 


Test case group 


SIP-SIP/SIP-I/TP 


Reference 


5.4.3.2, 6.11.2, 6.11.2/[24] 


SELECTION EXPRESSION 


[Network A] SE 1 7 AND SE 47 AND SE 64 


Test purpose 


SIP-I support. SUS message transferred in an INFO request call released. 

BICC/ISUP - SIP-I interworking applies in the originating network User A is 
located in network A and user B is located in network B. A session is already 
established. Ensure that an INFO request is sent from Network A to Network B 
and an ISUP SUS message is encapsulated containing a Suspend/resume 
indicator set to ISDN subscriber initiated. Ensure that an BYE request is sent 
from Network A to Network B and an ISUP REL message is encapsulated 
containing a Cause value set to #102. 


Configuration 


User A is subscribed to the Terminal Portability supplementary service 


SIP Parameter 


INFO 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
SUS 

Suspend/resume indicator 
ISDN subscriber initiated 

BYE 

Content-Type: application/isup;version=itu-t92 
Content-Disposition: signal;handling=required 
REL 

Location 

public network serving remote user 
Cause value 
102 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 

INFO(SUS) * 
200 OK INFO 

BYE(REL) 

200 OK BYE 


Comments 


A session is already established 

Check: Is an ISUP SUS message encapsulated in the INFO request and the 
Suspend/resume indicator set to ISDN 'subscriber initiated'? 

Check: Is an ISUP REL message encapsulated in the BYE request and the 
Cause value set to #102? 

Repeat this test in reverse direction. 
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7.2 Number Portability 



Test case number 


SS NP 001 


Test case group 


SIP-SIP/NubP 


Reference 


5.3, 5.4/[2] 


SELECTION EXPRESSION 


[Network A] SE 13 


Test purpose 


Request line in the INVITE contains the number portability indication. 

User A attempts to call user B ported to network B. Ensure that the userinfo in 
the INVITE contains a destination number in the global number format, an 'rn' 
parameter containing the Number Portability Routing Number in a global number 
format with hex digits and optional the 'npdi' parameter. 


Configuration 




SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;npdi][; rn=(Number portability routing number)] 
@<hostname>;user = phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Check: Is the URI in the userinfo of the Request line in a global number 
format? 

Check: Is the URI rn parameter containing the Number Portability Routing 

Number in a global number format? 
Check: Is optional the URI parameter 'npdi' present? 
Check: Is the user parameter set to 'phone'? 
Repeat this test in reverse direction. 




Test case number 


SS NP 002 


Test case group 


SIP-SIP/NubP 


Reference 


5.3, 5.4/[2] 


SELECTION EXPRESSION 


NOT [Network A] SE 13 


Test purpose 


Request line in the INVITE without npdi parameter. 

The Network A does not have a Number Portability database. User A attempts to 
call user B ported to network B. Ensure that the userinfo in the INVITE contains 
a destination number in a global number format and a npdi URI parameter is not 
present. 


Configuration 




SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>@<hostname>;user = phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Check: Is the URI in the userinfo of the Request line in a global number format 

without npdi parameter and number portability routing number? 
Check: Is the user parameter set to 'phone'? 
Repeat this test in reverse direction. 
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7.3 Accounting 



Test case number 


SS acc 001 i 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records > 1 s. 

Accounting of a confirmed session with a duration > 1 s. Verify the duration of 
the active session stored in the CDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 5 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 002 I 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records < 1 s 

Accounting of a confirmed session with a duration of < 1 min. Verify the duration 
of the active session stored in the CDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 5 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 003 I 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records > 15 min. 

Accounting of a confirmed session with a duration of > 15 min. Verify the 
duration of the active session stored in the CDR of both networks compared with 
the duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 1 5 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 004 I 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records 25 min. 

Accounting of a confirmed session with a duration of 25 min. Verify the duration 
of the active session stored in the CDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 25 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 005 I 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records more than 30 min. 

Accounting of a confirmed session with a duration of > 30 min. Verify the 
duration of the active session stored in the CDR of both networks compared with 
the duration in the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 35 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 006 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records more than 60 min. 

Accounting of a confirmed session with a duration between 60 min and 120 min. 
Verify the duration of the active session stored in the CDR of both networks 
compared with the duration in the monitored message flow at the Interconnection 
Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session at the earliest 61 min and at the latest 1 1 9 min. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 007 I 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records more than 24 hours. 

Accounting of a confirmed session with duration > 24 h with change of date. 
Verify the duration of the active session stored in the CDR of both networks 
compared with the duration in the monitored message flow at the Interconnection 
Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 24 hours. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 008 I 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records less than 1 s. 

Accounting of a confirmed session with duration <1 s. Verify the duration of the 
active session stored in the CDR of both networks compared with the duration in 
the monitored message flow at the Interconnection Interface. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 
200 OK INVITE 

ACK 
Communication 
BYE 
200 OK BYE 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is the session confirmed. 

3. Terminate the session after 0,9 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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Test case number 


SS acc 009 


Test case group 


SIP-SIP/ACCOUNTING 


Reference 




SELECTION EXPRESSION 




Test purpose 


Comparison of Charging Data Records session not confirmed. 

Accounting of an unsuccessful session in the early dialogue. Verify the duration 
of the call attempt stored in the CDR of both networks compared with the 
duration in the monitored message flow at the Interconnection Interface if 
applicable. 


Configuration 




SIP Parameter 




Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
180 Ringing 

BYE/CANCEL 
200 OK BYE/CANCEL 
4- 487 Request Terminated 
ACK 


Comments 


1 . Setup a call from network A to network B. 

2. Verify is an early dialogue established. 

3. Terminate the early dialogue after 20 s. 

4. Determine the duration of the session from the trace of the call monitor. 

5. Compare the following information elements indicated in the CDR's of both 
networks: 

• calling party number 

• called party number 

• timestamp 

• callduration 

• callsetuptime (optional) 

6. Check the duration indicated in the CDR against the duration in the call 
trace. 

7. Repeat this test in reverse direction. 
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7.4 Carrier Selection 



Test case number 


SS csel 001 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User selects an operator 'call-by-cair. 

User A and user B are located in network A Ensure that user A is able to call 
user B and user A is able to select network B as a selected carrier 'call-by-caH'. 


Configuration 


User in network A is not presubscribed 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 
INVITE 2 
Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the 'rn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 002 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1 .10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User is presubscribed to operator B. 

User A and user B are located in network A. Ensure that user A is able to call 
user B and user A is preselected to network B as a selected carrier. 


Configuration 


User in network A is presubscribed to network B 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 
INVITE 2 
Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the 'rn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 003 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User is presubscribed to an operator unequal to B, and overrides the 
preselection with call-by-call via operator B. 

User A and user B are located in network A. User A is preselected to a network 
unequal to network B. Ensure that user A is able to call user B and user A is able 
to select network B as a selected carrier 'call-by-caH'. The preselected carrier is 
ignored. 


Configuration 


User in network A is presubscribed to network B 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 
INVITE 2 
Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the Yn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 004 


Test case group 


SIP-SIP/CS 


Reference 


5.7.1.10/[2] 


SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 


Test purpose 


User is presubscribed to an operator not operator B, and overrides the 
preselection with call-by-call via operator B. 

User A and user B are located in network A. User A is preselected to a network 
unequal to network B. Ensure that user A is able to call user B and user A is able 
to select network B as a selected carrier 'call-by-caH'. The preselected carrier is 
ignored. 


Configuration 


User in network A is presubscribed not to network B 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>[;cic=(carrier ID)]@<hostname> user=phone SIP/2.0 

INVITE: Request line 

sip: + <CC> <NDC> <SN>;npdi 

[;rn=<Number portability routing number>]@<hostname>; 
user=phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 
INVITE 2 
Apply post test routine 


Comments 


Check: Is the 'cic' tel uri parameter present in the Request URI in the INVITE 

sent from network A to network B identifying the selected carrier? 
Check: Is the 'npdi' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
Check: Is optional the Yn' parameter present in the Request URI of the INVITE 

request sent from network B to network A? 
NOTE 1 : The 'cic' parameter may be absent according national regulations or 

national agreements. 
NOTE 2: It is possible that further informations are available in the Request line 

regarding the end user charging in case of Carrier selection. 
Repeat this test in reverse direction. 
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Test case number 


SS csel 005 


Test case group 


SIP-SIP/CS 


Reference 




SELECTION EXPRESSION 


[Network A] SE14 AND [Network B] SE15 AND [Network A] SE34 


Test purpose 


User is preselected to operator B. Transit of CUG information -OA. 

An originating user in a CUG Outgoing Access not allowed preselected to 
Network B and calls to a user in the same CUG. The session establishment is 
successful. 


Configuration 


User in network A is presubscribed to network B 
Users in network A are in the same CUG 


SIP Parameter 


INVITE: Request line 

sip: + <CC> <NDC> <SN>@tariff.<hostname> 
user=phone SIP/2.0 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...:cug> 

<..: cugCommunicationlndicator>1 1 </...: cugCommunicationlndicator> 
<...:cug> 

INVITE: Request line 

sip: + <CC> <NDC> <SN@<hostname>;user=phone SIP/2.0 

Content-Type: application/vnd.etsi.cug+xml 
Content-Disposition: ....;handling= required 

<...:cug> 

<..: cugCommunicationlndicator>1 1 </...: cugCommunicationlndicator> 
<...:cug> 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 1 
INVITE 2 
Apply post test routine 


Comments 


Check: Is the sub domain pattern 'tariff present at the beginning of the 
hostportion only of the initial INVITE sent from network A to 
network B? 

Check: Is the 'npdi' parameter present in the userinfo of the INVITE request 

sent from network B to network A? 
Check: Is optional the 'rn' parameter present in the userinfo of the INVITE 

request sent from network B to network A? 
Check: Contains the XML body in the INVITE a 'cugCommunicationlndicator' 

element set to '1 1 ' as a 'cug' child element? 
Check: Is the session setup not rejected? 
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7.5 Emergency call 



Test case number 


SS ecall 001 


Test case group 


SIP-SIP/EmC 


Reference 


5.2.10, 5.7.1. 14/[2] 


SELECTION EXPRESSION 




Test purpose 


Request line in the INVITE. 

User A attempts to call a PSAP located in network B. Ensure that the Request 
line in the INVITE contains the emergency number and a 'rn' parameter 
containing the PSAP routing number. In addition a location information may be 
present: 

• Geolocation header 

• P-Access-Network-lnfo header 

• National solution to convey location information 
to make location information available for the PASP. 


Configuration 




SIP Parameter 


INVITE: Request line 

sip+ <(emergency number)>[; rn =+<(PASP routing number)] 
@hostname>;user = phone SIP/2.0 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

INVITE 
Apply post test routine 


Comments 


Check: Is the URI in the userinfo of the Request line in a global number format 

containing the PSAP routing number? 
Check: Optional: Is the URI 'rn' parameter containing the PASP Routing 

Number? 

Check: Is the user parameter set to 'phone'? 
Repeat this test in reverse direction. 
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7.6 SIP Support of Charging 



Test case number 


SS sipc 001 


Test case group 


SIP-SIP/ SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful session from user A to user B via network B one single tariff. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with one single tariff covered in a XML MIME body in a reliable 
provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: 1 0Orel 

18xor200 OK 
Require: 1 0Orel 

ContentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control I ndicators 
originationldentification 

uuiidiuy ^upuui icily 


Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 

INVITE 

1 8x(crgt) 
PRACK 
200 OK PRACK 


CASE B 


200 OK INVITE(crgt) 
Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to '100rel' 

Check: Is the Require header in the response containing the tariff information 

Check: Is the messageType 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'currentTariffCurrency'? 
Check: Represents the currencyFactorScale in the 

communicationChargeSequenceCurrency element the applicable 
tariff? 

Check: Is the tariffDuration element set to '0'? 

Check: Is the optional element 'currency' set to 'EUR' if present? 

Repeat this test in reverse direction. 
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Test case number 


SS sipc 002 


Test case group 


SIP-SIP/ SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful session from user A to user B via network B several tariffs in 
one sequence. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with several tariffs in a sequence covered in a XML MIME body in a 
reliable provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: 1 0Orel 

18xor200 OK 
Require: 1 0Orel 

ContentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

cu rrentTariff Cu rrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 

subTariffControl ^^^^^^^^^^^ 
communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control Indicators 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 

INVITE 

18x(crgt) 
PRACK 
200 OK PRACK 


CASE B 


200 OK INVITE(crgt) 
Apply post test routine 


Comments 


Check: Is the Supported header in the initial INVITE set to '1 OOrel'? 
Check: Is the Require header in the response containing the tariff information 
set to '1 OOrel'? 

Check: Is the messageType 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'currentTariffCurrency'? 
Check: Are there more than one communicationCharge 

SequenceCurrency elements present in the currentTariffCurrency 

element? 

Check: Represents the currencyFactorScale in the communicationCharge 

SequenceCurrency elements the applicable tariffs? 
Check: Is the tariffDuration element in the last applicable tariff set to '0'? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 003 


Test case group 


SIP-SIP/ SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful session from user A to user B via network B with call attempt 
charge. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with a call attempt charge covered in a XML MIME body in a reliable 
provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: 1 0Orel 

18xor200 OK 
Require: 1 0Orel 

ContentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control Indicators 
callAttemptChargeCurrency 
currencyFactor 
currencyScale 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 

INVITE 

1 8x(crgt) 
PRACK 
200 OK PRACK 


CASE B 


200 OK INVITE(crgt) 
Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to '1 OOrel'? 
Check: Is the Require header in the response containing the tariff information 
set to '1 OOrel'? 

Check: Is the messageType a 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'callAttemptChargeCurrency'? 
Check: Represents the currencyFactorScale in the 

callAttemptChargeCurrency element the applicable tariff? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 004 


Test case group 


SIP-SIP/ SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful session from user A to user B via network B with call setup 
charge. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with a call setup charge covered in a XML MIME body in a reliable 
provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: 1 0Orel 

18xor200 OK 
Require: 1 0Orel 

ContentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariffCurrency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control Indicators 
callSetupChargeCurrency 
currencyFactor 
currencyScale 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 

INVITE 

1 8x(crgt) 
PRACK 
200 OK PRACK 


CASE B 


200 OK INVITE(crgt) 
Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to '1 OOrel'? 
Check: Is the Require header in the response containing the tariff information 
set to '1 OOrel'? 

Check: Is the messageType a 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffCurrency element set to 'callSetupChargeCurrency'? 
Check: Represents the currencyFactorScale in the 

callSetupChargeCurrency element the applicable tariff? 
Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 005 


Test case group 


SIP-SIP/ SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful session from user A to user B via network B with a next tariff. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a tariff 
information with a next tariff and tariff switch over time covered in a XML MIME 
body in a reliable provisional or successful final response. 


Configuration 




SIP Parameter 


INVITE: 

Supported: 1 0Orel 

18xor200 OK 
Require: 1 0Orel 

ContentType: application/vnd.etsi.sci+xml 
Content-Disposition: render; handling=optional 

messageType 
crgt 

chargingControllndicators 
chargingTariff 
tariffCurrency 

currentTariff Currency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control I ndicators 
tariff SwitchCurrency 
nextTariff Currency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control I ndicators 
tariffSwitchOverTime 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) 

CASE A 


Interconnection Interface SIP (Network B) 

INVITE 

1 8x(crgt) 
PRACK 
200 OK PRACK 


CASE B 


200 OK INVITE(crgt) 
Apply post test routine 


Comments 


Check: Is the supported header in the initial INVITE set to '1 OOrel'? 
Check: Is the Require header in the response containing the tariff information 
set to '1 OOrel'? 

Check: Is the messageType 'crgt' present in a 1xx provisional or a 200 OK 

INVITE final response? 
Check: Is the tariffSwitchCurrency element set to 'nextTariffCurrency'? 
Check: Represents the currencyFactorScale in the 

communicationChargeSequenceCurrency element the next tariff? 
Check: Is the time to change the tariff indicated in the tariffSwitchOverTime 

element? 

Check: Is the optional element 'currency' set to 'EUR' if present? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 006 


Test case group 


SIP-SIP/ SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful change of a current tariff and next tariff during an active 
session. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a new 
tariff information with several current tariffs and several next tariffs covered in a 
XML MIME body in an INFO request. 


Configuration 




SIP Parameter 


INFO 

ContentType: application/vnd.etsi.sci+xml 

messageType 
crgt 

chargingControllndicators 
chargingTariff 

tariffCurrency 

currentTariff Currency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control I ndicators 
tariff SwitchCurrency 
nextTariff Currency 

communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
communicationChargeSequenceCurrency 
currencyFactorScale 
currencyFactor 
currencyScale 
tariffDuration 
subTariffControl 
tariff Control I ndicators 
tariffSwitchOverTime 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
INFO 
200 OK INFO 
Apply post test routine 


Comments 


Check: Is the messageType 'crgt' present in the INFO request? 
Check: Is the tariffCurrency element set to 'currentTariffCurrency'? 
Check: Represents the currencyFactorScale in the 

communicationChargeSequenceCurrency elements the current tariffs? 
Check: Is the tariffSwitchCurrency element set to 'nextTariffCurrency'? 
Check: Represents the currencyFactorScale in the 

communicationChargeSequenceCurrency elements the next tariffs? 
Repeat this test in reverse direction. 
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Test case number 


SS sipc 007 


Test case group 


SIP-SIP/SIP_charging 


Reference 


B.2.3/[19] 


SELECTION EXPRESSION 


SE 16 


Test purpose 


Successful additional charge during an active session. 

User A is located in network A and network B is responsible for charging (CDP) 
in case of carrier selection or service. Ensure that the network B sends a new 
tariff information with additional charge covered in a XML MIME body in an INFO 
request. 


Configuration 




SIP Parameter 


INFO 

ContentType: application/vnd.etsi.sci+xml 

messageType 
aocrg 

chargingControllndicators 
addOnCharge 

addOnChargeCurrency 

currencyFactor 

currencyScale 
originationldentification 
currency (optional) 


Message flow 

SIP (Network A) Interconnection Interface SIP (Network B) 

A confirmed session already exists 
INFO 
200 OK INFO 
Apply post test routine 


Comments 


Check: Is the messageType 'aocrg' present in the INFO request? 
Check: Is the addOnCharge element set to 'addOnChargeCurrency'? 
Check: Represents the currencyFactorScale the add on tariff? 
Repeat this test in reverse direction 



7.7 Quality of Service 
7.7.1 Reference Configurations 
7.7.1 .1 Backbone Configuration 

Figure 7.7-1 shows the backbone configuration. 
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Figure 7.7-1 : Backbone 
7.7.1 .2 PSTN/ISDN classic access Configuration 

Figure 7.7-2 shows the PSTN/ISDN classic access configuration. 
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Figure 7.7-2: Reference configuration for PSTN/ISDN with classical access 
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7.7.1 .3 NGN PSTN/ISDN access Configuration 

Figure 7.7-3 shows the NGN PSTN/ISDN classic access configuration. 
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Figure 7.7-3: Reference configuration for NGN with PSTN/ISDN access 



7.7.1 .4 Access DSL Configuration 

Figure 7.7-4 shows the xDSL access configuration. 
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Figure 7.7-4: Reference configuration for DSL access 



7.7.1.5 



Delay Values 



The requirements for the backbone delay, Network parameters: End-to-End Delay, Talker Echo Loudness Rating, R 
Value Delay with regional propagation delay (1 400 km/1 1 ms) are contained in clause 4 of TR 102 775 [i.3] 

7.7.2 Test purposes for Quality of Service test 



Test case number 


SS qos 001 


Test case group 


SIP-SIP/QoS 


Transmission Type: 


Voice 


Preconditions user 
segment A: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal "single-talk" to Interface A and determine Delay D JB i 
Apply signal "single-talk" to Interface B and determine Delay D JB 2 


Preconditions user 
segment B: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal single-talk to Interface A and determine Delay D JB i 
Apply signal single-talk to Interface B and determine Delay D JB2 


Requirement 


D JB i = D JB2 Delay jitter for Voice 


Test objective 


Delay Voice test with loopback 


Measurement procedure 


After establishing a voice call from the user segment A to user segment B, determine the 

round trip delay in the sending and receiving direction. Based on the 

measured delays in the user segment A and user segment B determine the transit 

segment delay. 

Loop in user segment B 

Dtr seg A-B = (D SU m seg A-B" Dj B i S eg B" Dj B 2segA)/2 

Loop in user segment A 

Dtr seg B-A = (D S um seg B-A ~ Dj B i S eg B" Dj B 2segA)/2 


Calling station 


The amplitude of the tone is -16 dBmO 


Called station 


The amplitude of the tone is -16 dBmO 


Delay loop 


1 000 ms 
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Test case number 


SS_qos_002 


Test case group 


SIP-SIP/QoS 


Transmission Type: 


Voice 


Preconditions user 
segment A: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal "single-talk" to Interface A and determine Delay D JB i and D JB2 


Preconditions user 
segment B: 


Reset Jitter Buffer 1 and Jitter Buffer 2 (e.g. by establishing a new call) 
Apply signal "single-talk" to Interface A and determine Delay D JB i and D JB2 


Requirement 


D JB i = D JB2 Delay jitter for Voice 


Test objective 


Delay Voice test with synchronous tests system 


Measurement procedure 


After establishing a voice call from the user segment A to user segment B, determine the 
delay of the end-to-end in the sending and receiving direction. Based on the 
measured delays in the user segment A and user segment B determine the transit 
segment delay. 

Dtr-segA- B = D SU m-seg A- B _ Dj B i se g B 
Dtr-seg B-A= D S um-seg B-A - Dj B 2seqA 


Calling station 


The amplitude of the tone is -16 dBmO 


Called station 


The amplitude of the tone is -16 dBmO 
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